Bug 118375

This is still there with the final version.
Could somebody please look into it? Perhaps this is because of the windows "desktop.ini" files.

...and still there with 10.1 beta3
IMHO this should get a little higher priority since writing on FAT partitions should work without any glitches.

Can you reproduce with a file system generated with mkfs.vfat? E.g.,

  dd if=/dev/zero of=fat32 bs=512 count=16384
  losetup /dev/loop0 fat32
  mkfs.fat32 /dev/loop0
  mount -o rw,users,gid=users,umask=0002,utf8 /dev/loop0 /mnt

Otherwise, can you somehow create a filesystem image you can attach, preferably with all unused blocks zeroed out so that it compresses well? This might be a UTF-8 character encoding problem. Does this occur with all directoris that contain spaces? Does it also occur with a directory which contains spaces that you have created on Linux?

No, this is an "imported" Windows partition. It doesn´t have something to do with spaces, e.g. I can´t write to "/windows/D/Eigene Dateien" but I can write to its subfolder "/windows/D/Eigene Dateien/Icons" for example.
I don´t think I can create a filesystem image since it contains my provate data and also it´s way too big. And those steps above, do they change anything with my partitons?I usually don´t do "low-level" partitioning under linux.

> And those steps above, do they change anything with my partitons?
> I usually don´t do "low-level" partitioning under linux.

The commands create a filesystem in a file and then mounts that filesystem (aka a loop-mounted filesystem); in the particular sequence, the commands are harmless. If that all sounds greek to you, a safe bet would be not to do low-level things like that on the command line though.

Will try to reproduce here. Can you give us some details about your configuration: which version of Windows are you using? Which language?

I´ve a german version of Windows XP Professional.
Thie happens both with 10.0 final and with the newest beta. The partition is mounted as:

/dev/sda5 on /windows/D type vfat (rw,noexec,nosuid,nodev,gid=100,umask=0002,utf8=true)

I was able to reproduce it here as well on SLED beta8.

I copied a whole user directory from one of our WinXP hosts to a USB drive and attached it to the SUT.

Michael, would you mind providing the output of ls -la on the mountpoint of your windows drive.

michael@r098088:/windows/D> ls -la
insgesamt 160
drwxrwxr-x   6 root users 32768 1970-01-01 01:00 .
drwxr-xr-x   7 root root    168 2005-11-02 23:43 ..
dr-xr-xr-x  34 root users 32768 2005-11-02 20:01 Eigene Dateien
drwxrwxr-x   2 root users 32768 2005-10-19 00:43 Recycled
drwxrwxr-x   4 root users 32768 2005-10-03 15:21 System Volume Information
drwxrwxr-x   2 root users 32768 2005-11-03 23:59 .Trash-michael

It's wrong that FAT filesystems have _no_ permission support.

FAT has a limited set of permissions - including a read-only bit.

Just tested on a VFAT partition:
# mkdir 1 2
# chmod -w 1
# ls -l
dr-xr-xr-x 2 root root 4096 2006-04-08 01:39 1
drwxr-xr-x 2 root root 4096 2006-04-08 01:39 2

Therefore the solution of this bug could be a simple
chmod +w "Eigene Dateien"   ;-)

I changed it to be like this:
drwxrwxr-x  34 root users 32768 2005-11-02 19:01 Eigene Dateien
drwxrwxr-x   2 root users 32768 2005-10-18 23:43 Recycled
drwxrwxr-x   4 root users 32768 2005-10-03 14:21 System Volume Information

but it still doesn´t work. Also the read-only bit isn´t set, I can write from Windows without any Problems. What I find strange is that I can write to certain subfolders of "Eigene Dateien", but not to the folder itself or to folders like "My Videos", not even as root.

closing according to comment #11

Hm, please read my comment #12.
I don´t know why you close this, as I clearly stated that this isn´t the problem.

Oh well, ancient times. Only reasonable resolution is "FIXED" now.