Comment 2 for bug 688576

I recently found out what is causing the problem (so, we can now use a workaround until the fix be available)...

The problem happens in NTFS-3G program (when mount NTFS filesystem)... It seems that when Nautilus or Dolphin try to mount a partition (as the user clicks in the partition icon), HAL calls MOUNT.NTFS (that is linked to NTFS-3G) with the options RW,UID=USERNUMBER,GID=USERNUMBERGROUP,FMASK=177,DMASK=077...

So I verified every options listed to exactly identify which one is causing of the problem...

It seams that when a partition is mounted by NTFS-3G without the options UID=,GID=,UMASK=077 (or FMASK=177,DMASK=077), the system cannot create the path .TRASH-UID as well as the files inside it (the trashed files)...
For me this don't make sense, because if I use the option UMASK=000 (that is more permissive than UMASK=077), the trash folder is not created (this don't make sense)...

Therefore, I think this problem is a BUG and shall be solved as soon as possible, since it limitates the user preferences related to UMASK...

PS: The UID and GID options are exclusive necessary to the correct opening of the files inside the folder... Without this option, the trash folder is created, but the user cannot access the files inside the mounted point (mounted partition, etc)... What do cause the trash problem is the UMASK option (or FMASK together with DMASK)...

This problem may be associated with other filesystems as well as NTFS-3G, because it seams (I did not test the problem with other filesystems, because I only work with EXT4 and NTFS filesystems) that the creation of the trash folder is done by another program inside LINUX that works both inside KDE and GNOME (so, it's an independent program that works with Nautilus and Dolphin)... Therefore, the filesystems that have the options UMASK,FMASK,DMASK may be affected by this bug...

I hope I could help,

André M.