Hal and fuse filesystem support

[David Zeuthen]

This sounds like a file system driver / pmount bug to me. I think the
pmount stuff and/or the Ubuntu GNOME uses eject(8) by default instead of
just unmounting (which is very silly IMO), perhaps that's why. I'd
suggest filing a bug with your distro.

Btw, can you attach the output of 'mount' when the NTFS volume is
mounted and you have write access? That will help answer my earlier
question about what mount options are to be used. Thanks.

On Fri, 2006-10-06 at 04:13 +0200, Florent Mertens wrote:
> I'm actually trying your change, and i encounter a little problem
> when unmounting an usb device.
> I set hal to use ntfs-3g instead of ntfs by default, and i tried to plug
> an usb NTFS device. With a patched pmount which add ntfs-3g support, 
> mounting comes without a itch and i had read/write access. So i copy a
> large file and all seams to work.
> The problem came when unmounting. I used the eject button of nautilus,
> unmouting seams to work, but when i replug it to check how it worked, 
> i had the bad surprise to see that the file was corrupted.
> I first thought that it was a driver problem (even if i never encounter
> any problem with it), but when i retry the same things and unmount by
> CLI (with pumount) instead of the eject button, it worked great.
> A lots of test confirm me that, it seams that there is a bad interaction
> when using the eject button, that stop the transfer of the file before
> the end, leaving it corrupted.
> I check the output of hal when unmounting an ntfs & an fat32 (the same
> one but format in fat32) USB drive with the eject button, and it seams
> that there is a little difference. With the fat32, hal receive first
> 00:31:22.229 [I] osspec.c:232: SEQNUM=2473, ACTION=umount,
> SUBSYSTEM=block, DEVPATH=/sys/block/sda/sda1, DEVNAME=, IFINDEX=0, but
> not with ntfs (all the output is attach).
> 
> What do you think could cause this problem ?
> 
> Le mercredi 04 octobre 2006 à 10:43 -0700, Dan Nicholson a écrit :
> > On 10/4/06, David Zeuthen <david at fubar.dk> wrote:
> > >
> > > Think this was fixed with this commit
> > 
> > Cool. I tried using the ntfs-fuse gnome-vfs module a few weeks back
> > with hal-0.5.7 and thought it was broken.
> > 
> > > as you can see, but we need to pass the right mount options so it's
> > > readable by the user - do you know what mount options are good to pass
> > > so the user can read/write to the NTFS partition?
> > >
> > > Please let me know so I can add the right bits to the hal property
> > > volume.mount.valid_options, cf.
> > >
> > >  http://gitweb.freedesktop.org/?p=hal.git;a=blob;hb=HEAD;f=fdi/policy/10osvendor/20-storage-methods.fdi
> > 
> > I'm not sure what the safest options to pass are, but it seems that
> > the charset settings need to be allowed for ntfs in general. For the
> > ntfs driver, this appears to be nls= or the deprecated iocharset=.
> > 
> > http://kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;hb=HEAD;f=Documentation/filesystems/ntfs.txt
> > 
> > For ntfs-fuse, the setting is locale=.
> > 
> > http://man.linux-ntfs.org/ntfsmount.8.html
> > 
> > For both, fmask and dmask would be nice. I don't know about the write
> > permissions.
> > 
> > --
> > Dan
> _______________________________________________
> hal mailing list
> hal at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/hal