See http://lists.freedesktop.org/archives/hal/2008-October/012472.html (might be handy to read the prior messages in the thread)
Created attachment 1924 Example fdi file for ntfs-3g Here's the example fdi file mentioned in the hal ml archive (the one that was attached to the mail).
Oh, and Benny, I know you're terribly busy right now, so sorry to flood your inbox, but... While this is being implemented, it would be nice to have support for custom mount options... :-)
Created attachment 1939 Patch to allow exo-mount to use ntfs-3g
I have worked up a small patch to use the new volume.fstype.alternative stuff added to hal. Its not 100% as I had to tweak the example fdi file and change volume.fstype.alternative from a strlist to a string. And I was unable to get mounting with the uid option to work. Once the hal spec for 5.12 is complete it should not be much work to adapt to it.
The patch as is does result in exo using ntfs-3g to mount the filesystem; however, the uid does not seem to be getting passed as an argument for whatever reason. There's another problem too - I just talked with DannyK (hal dev), and we also need support for different alternative filesystem drivers; see the latest version of the hal spec for details: http://people.freedesktop.org/~dkukawka/hal-spec-git/hal-spec.html#device-properties-volume
Created attachment 1968 Updated patch for ntfs-3g support
Created attachment 1969 new fdi file The new fdi file adds the 'preferred' fs driver line; whether this should be in the fdi file shipped by ntfs-3g or not is undetermined as of yet
Okay, there's the next round of attachments (sorry for the multiple posts - it wasn't immediately obvious how to attach two files *and* make a comment at the same time), and I think this works as desired (pending resolution of a bug in hal - http://bugs.freedesktop.org/show_bug.cgi?id=17684 ) The new patch, along with the new fdi file, results in exo using the ntfs-3g driver to mount the filesystem, and it tries to send the uid as a mount argument, but due to hal bug mentioned above, the error message displayed is something to the effect of "TODO: Rethink extra mount options." I'm pulling latest hal git now and will test with it, but assuming no problems are found, I think these will work.
Created attachment 1970 Another updated patch Okay, this latest patch is tested with a hal git snapshot from today, and it appears to work exactly as desired. liberty $ mount | grep -i ntfs /dev/sda on /media/CRUZER_NTFS type fuseblk (rw,nosuid,nodev,allow_other,default_permissions,blksize=4096) liberty $ ls -ld /media/CRUZER_NTFS/ drwx------ 1 rworkman root 4.0K 2008-11-12 14:51 /media/CRUZER_NTFS// Benny, does the way I put in the umask addition look okay to you? I considered using dmask and fmask instead, but I decided against it - I would have done fmask=0177, but then maybe some users will legitimately want some files to be executable on the filesystem, so this would be bad for them. umask=0077 instead will make all files executable, which might not be ideal, but at least it allows those who want it to have it.
Do you really want 'allow_other' in there? That'll let other users access the device...
Well, I don't know how to remove it via exo, so passing the uid and umask settings work around it. If my understanding is correct (my testing here indicates that it is, but I could of course be wrong), then those two coupled with the default_permissions option cause the effective filesystem permissions to be respected. In my testing, I switched to a test user account and was unable to cd into the mountpoint or read/write files in/to it.
As much as I hate to do so, I'm going to have to abandon any hope of this being part of the upcoming 4.6 release. There are at least two blocking issues of which I'm aware: 1. With this patch, attempting to mount a VFAT thumbdrive results in this: http://slackware.com/~rworkman/error.jpg I don't see a connection between icon usage and any of the code changes in the patch, but it's obviously related - if I build exo without the patch, it works fine. 2. For whatever reason, the "uhelper=hal" mount option is not getting added when an ntfs-3g device is mounted. This is defined in $hal-source/tools/hal-storage-mount.c like so: #ifdef HAVE_UMOUNT_HAL mount_option_str = g_string_new (MOUNT_OPTIONS ",uhelper=hal"); #else mount_option_str = g_string_new (MOUNT_OPTIONS); #endif and it obviously is correctly built, as the uhelper option is passed to the vfat drive. Basically, I don't know where to look next at troubleshooting either of these issues, so all of this will have to wait for 4.8, I suppose.
Created attachment 2545 Another try... New patch against current exo git. Testing here (with an updated fdi file - I'll attach it in a moment) looks mostly good, I think. liberty $ exo-mount -h \ '/org/freedesktop/Hal/devices/volume_uuid_77706E59199DA196' liberty $ mount | grep -i ntfs /dev/sdb1 on /media/CRUZER_NTFS type fuseblk (rw,nosuid,nodev,allow_other,default_permissions,blksize=4096) liberty $ ls -ld /media/CRUZER_NTFS/ drwx------ 1 rworkman root 8192 2009-09-23 10:02 /media/CRUZER_NTFS// liberty $ ls -l /media/CRUZER_NTFS/ total 8 drwx------ 1 rworkman root 4096 2007-01-01 18:33 Gateway_DX200/ drwx------ 1 rworkman root 4096 2009-09-11 00:03 Toshiba_A105-S4164_Drivers/ -rwx------ 1 rworkman root 0 2009-09-24 00:31 testfile* liberty $ exo-mount -u -h \ '/org/freedesktop/Hal/devices/volume_uuid_77706E59199DA196' ------------------------ There's still the problem of uhelper=hal not getting set, but honestly, while it would be nice, I'm not sure it's a showstopper: liberty $ umount /media/CRUZER_NTFS/ umount: /media/CRUZER_NTFS is not in the fstab (and you are not root) Even with that problem, unmounting works fine from the gui.
Created attachment 2546 New fdi file again Here's the fdi file needed - I think the comments in it pretty much explain the rationale.
Created attachment 2591 Fix some problems Made some updates to your patch. Could you try it?
*** Bug 5679 has been marked as a duplicate of this bug. ***
Committed a patch that makes mounting work with both ntfs (ro) and ntfs-3g (rw).
Thanks for the cleanup, Nick, and sorry for the delay in testing. I built the new -stable exo release today, and it works as expected. Much appreciation for the help!
Created attachment 2714 (more) correct fdi file Sorry for the spamming of a closed bug, but I wanted to put a fixed fdi file for ntfs-3g in here just in case someone stumbles across this bug and decides to use the fdi file. The old one had a couple of minor but inconvenient bugs that could cause ntfs filesystems to be unmountable by exo.