https://bugzilla.novell.com/show_bug.cgi?id=293433#c12
Bernhard Kaindl
The default for gnome-mount is to override ntfs with ntfs-3g which our version of HAL does not support. Try setting /system/storage/default_options/ntfs/fstype_override to the empty string, and see if that fixes your problem.
. of which he is right:
gnome-mount-0.6/ChangeLog
-------------------------------------------------------------------------------
2007-03-04 David Zeuthen
Reassing to KDE, they have only to use other parameter for the mount call for HAL to mount with fuse (set filesystem for ntfs-3g). No need to change anything here in HAL.
KDE and GNOME can do anything they want, as soon as they need to pass mount options specific for ntfs-3g: * force: GNOME provide a checkbox for this in case the mount withou force fails because the volume is dirty * we need to specify the locale of the user who asks for ntfs-3g to mount a filesystem, or he will either see only paths with only ASCII characters (that's the case when "mount -t ntfs-3g" is called without a non-US-ASCII locale set or garbage from non-ASCII characters if the charsets to not match, or worse, mangled pathnames end up on the disk when files are written. * We do not want to mount with rwxrwxrwx by default ( see bug 293429 ) * The user may want do specify "no_def_options" to make the whole volume completely hidden to all other users (they only get to see the mountpoint's name) or may want to use other permission-related options. For all this, KDE and GNOME are out of luck if HAL does not allow these these mount options, and we should really fix bug 293429, coolo set it to CRITICAL. So I'd say we need the allowed options from my attachment 156942 in comment 11 of this bug in HAL, we can't do anything. Whether HAL should do the remapping of ntfs to ntfs-3g or all the clients of HAL is of course the debatable question. On one hand, the solution in GNOME with gnome-mount's overide_fstype=ntfs-3g has the advantage that the user can individually disable that fstype-default of ntfs-3g, that has to be done for every user who wants to use the kernel's ntfs module by default and there is no way to set a system-level default of not-remapping and have the users which want the remap do it in their setup. When hal does the remapping in a policy file which is defined as %config (noreplace) in the spec file, a system-wide preset can be set there and users which do not want to use the system-wide default provided by hal, can opt out of it in both possible directions, when the hack in gnome-manager to always override the fstype is dropped/ reverted in our gnome-mount. hack is reverted/rejected. So I'm with Dirk Mueller, like he said in his comment #4 to this bug:
the part I don't understand is why HAL doesn't default to the right filesystem type, but instead requests the KDE team to add a custom hack (which is not portable to ivman or gnome or whatever else is out there).
So I am also against having such hacks like the one in gnome-manger currently to ivman, KDE and 'whatever else out there', and I want do drop that hack from gnome. I reassign to Danny because the ball is now in the quarter of HAL again, it *at least* needs to allow the valid ntfs-3g mount options when mounting ntfs-3g, and I propose to add a remapping in %config(noreplace), for which my attachment 156942 of comment #11 would just have to be packaged with HAL with this attribute, there is no other change necessary for that. I'll submit that change to STABLE, but I'm reassigning anyway because with the valid mount option, HAL's storage policy configuration definitely has to be extended in order for ntfs-3g to be usable in an international environment. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.