https://bugzilla.novell.com/show_bug.cgi?id=309074#c13 --- Comment #13 from Szabolcs Szakacsits <szaka@sienet.hu> 2007-09-25 07:37:39 MST --- (In reply to comment #9 from Bernhard Kaindl)
Let's revert the ntfs-3g change in yast2-storage and use the kernel's read-only NTFS filesystem as it's known to reliably mount the filesystem, whereas ntfs-3g does not do so yet (with the default options). Reason(s):
Unclean journal (and hibernated Windows) is handled exactly the same way by both drivers. Mount is allowed in read-only, disabled in read-write mode. Moreover NTFS-3G mounts much more volumes in both modes which can't be mounted by the kernel driver (mft mirror, mft bitmap, bootsector, hibernation file corruptions, etc.) If an unexpected error happens during mount then NTFS-3G also gives more, clear details and instructions how the problem can be solved.
Standard fstab semantics / fstab options not properly supported:
There isn't any fstab semantic which says a driver must automatic mount something read-only when it's hazardous to mount read-write.
* always mount the filesystem, no matter how broken the state of the filesystem is (if it *can* be mounted, mount it). Examples are:
This is exactly what NTFS-3G does. Unlike any other file system today, besides ZFS, NTFS-3G even fixes several types of corruption on-the-fly to be able to mount read-write. Here are the main cases of failing mounts (utils_mount_volume() in utils.c): - volume is not NTFS - volume is so corrupted that it can't be mounted - hibernated volume and unclean journal ==> see above and below - volume is already mounted or exclusively locked by something else - wrong device, it can't be opened
* FAT (which is very defensive and will spit error messages if it has errors, but if can mount, it will mount) and
So does NTFS-3G but it doesn't fallback to read-only. The other major difference is that the FAT driver still corrupts hibernated Windows since it can't detect it. I consider the automatic read-only mount of a hibernated volume and unclean journal case a security and usability risk when a user wants to mount read-write. I think user must be notified asap in these cases so he can act accordingly. If these problems can't be solved on the Windows side then the 'remove_hibfile' and 'reset_logfile' mount options can be used in the future (now the 'force' option is used for the latter) besides the 'ro' read-only mount.
* Support for the user/users options in fstab not given. Would need suid ntfs-3g which is not considered safe so far or kernel-supported user mounting, which is an proposal of the fuse maintainer but which is in mainline yet.
NTFS-3G provides the uid of the mounting user to FUSE, so it could check the rights what it doesn't do. If mount(8) and FUSE would fix their bugs then NTFS-3G wouldn't need to be setuid-root to support unprivileged mounts and the user/users mount options. -- 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.