Hello,

I'm using suse Linux 9.0 and Windows 2000 on my computer.
To have at least one partition, which both systems have read/write access to, I created a fat32 partition.
But now I have problems with Linux writing to this partition.
Writing to existing files works fine.
But creating new files or folders shows the following problem:

After creating a file or folder under Linux it looks good in the first place.
I can access and modify it as usual.
But after switching to Windows, I can't see this newly created file/folder.
After running scandisk, sometimes the file or folder suddenly appears, sometimes not.
If the file/folder doesn't appear, scandisk creates file chunks from "files without fat entry".
If the file/folder doesn't appear, it's lost under Linux as well.

So it looks like Linux is not able to create proper fat entries.
I've searched the web for this problem for quite a while.
No one seems to have the same problem.
Maybe it's just a configuration problem?

Here the according entry in fstab:

/dev/hda4 /e vfat defaults,gid=100,umask=0000 0 0

Does anyone have an idea?

Thanks,
Chily :o)

How are you creating these folders and or files? And what version of Linux are you using? Linux 9 is not a distribution. Have you upgraded your kernel at all, etc?

Bad entry in /etc/fstab. Single letter name for a directory is bad form--and can cause problems, call it: Win_E, Win_data, whatever. Also it is very bad form to add any non-standard directories to the / of the drive. Filesystems are normally mounted in /mnt/dir_name.

/dev/hda4 /mnt/Win_E vfat rw,auto,user 0 0

The 0 0 entry at the end tells the system to never do any file system checking, you may want to change that or run fsck before umounting or shutting down the machine. User (instead of users) because you want to be able to mount it a boot-up (auto) but you r-e-a-l-l-y don't want any binaries to run. It also, in cases of muliple users, enables you to log anything they do to the filesystem without restricting their access or being obvious. Command history is very easy to log by design (a little harder with the gui).

"info" mount. Read all of the manpages--again.

As long as the partition was created natively by windows I have never had a problem.

***I only have had to remind myself on occasion to use the MTOOLS when I make directories and other filesystem commands. Interpretation of the mkdir (and others) command is spotty when writing to vfat***

I have never used group id or umask entries, many of the options are only necessary if you are going to be "locking down" a machine for many people to use--only make things as complicated as they have to be. When I reviewed the docs, they mentioned suidperl being the exception to the implied nosuid option which is part of user.

The truely diabolical permission system (I called it that because of all of the interaction which needs to be plotted out when you really go for it.) is for hardened systems in public/general use by students at Carnegie-Mellon or MIT not for the home or small office environment.

The complex permission strategies in the university main-frame environment were (and are) a product of years of refinement and two generations of diabolical administrators. Administrators which could take pride in the synergistic effects they were able concoct with so few bits to work with on each file descriptor. The newer systems use access control lists, chroot, and such (you don't think MS came up with that idea do you?).

@trickykid:

I just used functions from the GUI (KDE).
* Copied folders from the Linux drive (reiserfs) with drag & drop in Konqueror.
* Created folders and files in Konqueror by right-clicking into a folder -> context menu -> new
* Created files by saving new file from Kate (text editor).

As I wrote: Suse Linux 9.0.
And no kernel or any other updates.


@Eqwatz:

The Linux system install program itself created it.
I just chose to create a FAT32 partition during the install process and it mounted it to /windows/e.

I moved the mount point to "/" cause i found this advice in another forum where they told how to set the permissions to the fat partition correctly.

In the beginning, I had another fstab entry, which I found in another forum:

/dev/hda4 /e vfat uid=0,gid=100,umask=000,exec,dev,suid,rw 1 1

But the "1 1" at the end didn't help with my problem.
Same buggy fat entries.

My partition was created by the Linux installer.
Do you think this might be the problem?
But if Linux creates the partition, why does Linux have the problem, not windows?

If you don't use the umask entry explicitly, just the user "root" has write access to the fat drive.
I had that problem before and found the mentioned solution in other forums.
I don't know, if it's especially bad to set the group of the drive to "users".
But I'm quite sure that it's not the cause of the buggy fat entries, is it?

Creating a partition is okay, as it is simply an entry in the partition table.

Make it a very strong habit to format any partition for any other O.S. (Linux aside) with it's own formatting tools.

The assumption of the partitioning/installation program is that you would rename the partition to something a little more descriptive and a little less like a "flag" or option to start a program.

BTW: you will want to chmod the permissions of the directory you create as the mount-point as rwxrwxrwx or 777; you were probably "root" when you created it.

Very bad form to screw with posix-style folder layout.

/ is the root of the drive. The only directories/folders which belong in there are the ones which are originally placed there by the O.S.. Linux is not windows.

To put things into perspective. The posix layout is not just a matter of tradition--although I'm sure that plays a role. The idea is that the layout is standardized for the purpose of disaster recovery and the application of scripting for back-ups and the like.

It is only for the purpose of "backward compatibility" that windows programs are allowed to place things there (in the root of the drive). If you used all new WHQL-approved programs for windows (which function and install according to the restrictions for nt4, 2000, and XP), you would find the same practices on that system as well.

Once you become more familiar with the different options you have open to you, you will find that the / of the drive is a mount-point for other partitions directly involved with the operation of the O.S.. /mnt is the mount-point for every other file-system, and each of the other top-level directories are mount-points as well--you build from simplicity -> complex. Alway keep things as simple as possible and build from there.

People are concerned with performance and stability with Linux.

There are some simple unofficial rules people have come up with over the years:

1: The larger the size of any filesystem--the more likely it is to hose up.

2: The larger a filesystem; the longer it takes to find something on it--for the system or for you.

3: Each filesystem type is better at some things than others. Select with purpose.

4: Disaster recovery should not, in most cases, involve the re-installation of the entire O.S..

5: Backups and restorations can be made simple, or really **&*%&^%&^$!!! Do everything in your power to make them simple.

6: Create as many partitions as you need, size them appropriately for their purpose, give them labels which will be informative in case of disaster, and leave enough space on the drive to create more for the purpose of moving stuff around, testing different configurations or resizing existing ones.

7: Disaster w-i-l-l happen + Back-ups can fail + Utilities don't always work. (Editing disks in hex is truely a pain in the *ss, but if the drive isn't dead, sometimes you can luck out w-h-e-n aforementioned event occurs--if you strictly follow placement strategies of your folders and files.)

/*---->I really believe that your usage of the "umask=" option is what is screwing you, really. Why? anything in the options string is going to over-ride the defaults which are normally present for the specified file system. FAT, VFAT, NTFS, CDFS, UDF don't have Linux permission structures on them as defined by their defaults set up by file type scripts. By including a umask entry, I think that you are over riding this, but it is legit according to the man-page. -->*/

Mount options in fstab:

"User" will allow non-root access, anyone who is properly logged on to the system can use it--it provides protection against executable files and other special files which may be present on the filesystem which may damage the working O.S..

An excerpt from http://www.linuxforum.com/man/mount.2.php

. . .Most devices are indicated by a file name (of a block special device),
like /dev/sda1, but there are other possibilities. For example, in the
that the filesystems are mounted simultaneously.

(ii) When mounting a file system mentioned in fstab, it suffices to
give only the device, or only the mount point.

(iii) Normally, only the superuser can mount file systems. However,
when fstab contains the user option on a line, then anybody can mount
the corresponding system.

Thus, given a line
/dev/cdrom /cd iso9660 ro,user,noauto,unhide
any user can mount the iso9660 file system found on his CDROM using the
command
mount /dev/cdrom
or
mount /cd

/*-->Note: the man-page in this instance does have /cd in the "/" and it used to be universally accepted--I was informed by some strongly opinionated individuals that mounted filesystems not actually part of the Linux O.S. belong in "/mnt". Generally, man-pages over-rule everybody elses opinion on the matter--expect the updated man-pages to reflect this or tune in for more "flame-wars". You can do what you wish, I kind of agree with the logic of the others. BTW--do you see gid, uid or umask options in the line above? Why not? You are mounting a file system aren't you? And you want to be able to mount it without being root--so what gives? */
. . . user Allow an ordinary user to mount the file system. The
name of the mounting user is written to mtab so that he
can unmount the file system again. This option implies
the options noexec, nosuid, and nodev (unless overridden
by subsequent options, as in the option line
user,exec,dev,suid).

users Allow every user to mount and unmount the file system.
This option implies the options noexec, nosuid, and nodev
(unless overridden by subsequent options, as in the
option line users,exec,dev,suid).. . . .


USERS is different, it implies that anyone can do anything. The syntax of the options is important, and will function like the use of gid and umask. It is strictly situational, and dependant on the granularity of control you may need to use for different situations.

. . . Mount options for fat
(Note: fat is not a separate filesystem, but a common part of the
msdos, umsdos and vfat filesystems.)

blocksize=512 / blocksize=1024 / blocksize=2048
Set blocksize (default 512).

uid=value and gid=value
Set the owner and group of all files. (Default: the uid and gid
of the current process.)

umask=value
Set the umask (the bitmask of the permissions that are not
present). The default is the umask of the current process. The
value is given in octal.

dmask=value
Set the umask applied to directories only. The default is the
umask of the current process. The value is given in octal.
Present since 2.5.43.

fmask=value
Set the umask applied to regular files only. The default is the
umask of the current process. The value is given in octal.
Present since 2.5.43. . . .

Mount options for vfat
First of all, the mount options for fat are recognized. The dotsOK
option is explicitly killed by vfat. Furthermore, there are

uni_xlate
Translate unhandled Unicode characters to special escaped
sequences. This lets you backup and restore filenames that are
created with any Unicode characters. Without this option, a '?'
is used when no translation is possible. The escape character is
':' because it is otherwise illegal on the vfat filesystem. The
escape sequence that gets used, where u is the unicode charac-
ter, is: ':', (u & 0x3f), ((u>>6) & 0x3f), (u>>12).

posix Allow two files with names that only differ in case.

nonumtail
First try to make a short name without sequence number, before
trying name~num.ext.

utf8 UTF8 is the filesystem safe 8-bit encoding of Unicode that is
used by the console. It can be be enabled for the filesystem
winnt Display the shortname as is; store a long name when the
short name is not all lower case or all upper case.

mixed Display the short name as is; store a long name when the
short name is not all upper case.

The default is "lower".

http://linuxbook.orbdesigns.com/ch17/btlb_c17.html O-O-Oh! Nifty. Another online book.
. . .Octal Numbers and Numeric File Mode
In the same manner that the decimal system uses 10 numbers, 0..9, octal representations use the numbers 0..7. In binary notation (as used by the computer), octal numbers can be represented with 3 bits.

Table 17-2
Numeric (Octal) Permissions

Octal Binary Permission>
0 000 > None
1 001 > x
2 010 > w
3 011 > wx
4 100 > r
5 101 > rx
6 110 > rw
7 111 > rwx


Octal one (001), two (010), and four (100) represent distinct bit patterns, representing execute, write, and read permission, respectively. Bear in mind that the order of access listed is user, group, and then other. So to assign user permission of read, write, and execute, and read-only access for group and other, the octal mode is 744. if you take out the 001 (binary) that represents user execute permission, use 644 for user read/write.

/**Umask is the logical ! of the permissions--the opposite so a umask=000 says anyone can do anything at all to the file system.**/

The umask command
Files are created in a variety of ways. When you create and save source code in an editor like vi, when you compile that code to create a running program, when you touch a non-existent file - all these methods and many more create files. When a file is initialized, there are permissions set from the beginning. For most files, this involves read and write - compiler output adds executable permission to the files it creates.

[bilbrey@bobo bilbrey]$ touch script02

[bilbrey@bobo bilbrey]$ ls -l script*
-rw-r--r-- 1 bilbrey users 71 Apr 25 18:24 test.c
In the example, script02 is created (using touch) with rw permission for the owning user, and read access for the owning group and all others. The default file creation permissions mask is preset. umask is the tool to modify that default. umask is a built-in command - a part of the bash shell (discussed in Chapter 15). umask lists or sets the bit mask (specifying which permissions are turned off) for file creation. The default umask is 022 octal, meaning to disallow write permission for group and other, but allow reading by all.

umask - Display or change the file creation mask

Usage : umask [option] [nnn]
-S Display mask in symbolic (rwx) mode
nnn Octal code specifying permissions to mask (if not symbolic)


Following the preceding example, which showed a file created with default permissions 022, we can modify the default permissions mask to allow read and write access for group as well as user, leaving other (world) access set to read only:

[bilbrey@bobo bilbrey]$ umask 002

[bilbrey@bobo bilbrey]$ touch script03

[bilbrey@bobo bilbrey]$ ls -l script*
-rw-r--r-- 1 bilbrey users 71 Apr 25 18:24 script02
-rw-rw-r-- 1 bilbrey users 71 Apr 25 18:27 script03

/***GID=users In the documentation, it seems to mention off-handedly that the machine assigns the gid (group id) numerical value or descriptor and writes it to /etc/group. Look in your system for group using locate. Locate group. I checked in some of my other documentation and on my own RH-9. The usual gid of users is 100. ***/



I haven't tried the newest, latest SuSE. But I have never had to use gid and umask--but then, I'm not a really heavy gui-user. It could be that the Desktop uses it's own fsutils and needs the additional information. A umask of 000 implies that every file is readable, writable, and executable on that filesystem.

For safety, use MTOOLS from the command-line to create directories in the Windows file-system. After that, drag and drop files to your heart's delight. You should be okay.