Hal and fuse filesystem support

[Florent Mertens]

Le jeudi 05 octobre 2006 à 22:37 -0400, David Zeuthen a écrit :
> This sounds like a file system driver / pmount bug to me. 

Correction : s/pmount/my patched pmount/

> 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.

That's right, but like martin said, there is a reason for that, and it's
work great with the official pmount. 
Anyway, turning off this policy make device mounted with ntfs-3g unmount
cleanly.

> 
> 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.

mount output for the NTFS device :
/dev/sda1 on /media/usbdisk type fuse
(rw,nosuid,nodev,noatime,allow_other)

> 
> 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
>