[Bug 300694] New: Installation aborts after error message that ntfs partition can' t be mounted
https://bugzilla.novell.com/show_bug.cgi?id=300694 Summary: Installation aborts after error message that ntfs partition can't be mounted Product: openSUSE 10.3 Version: Beta 1 Platform: i386 OS/Version: openSUSE 10.3 Status: NEW Severity: Blocker Priority: P5 - None Component: Installation AssignedTo: coolo@novell.com ReportedBy: mmichna@novell.com QAContact: jsrain@novell.com CC: holgi@novell.com Found By: Component Test When I try to install openSUSE 10.3 KDE on a machine which also has a Windows XP with a NTFS partition then I get a message (see screenshot) that it wasnt possible to mount the NTFS partition and that one shall use the -o force to mount that partition or add a entry to the fstab. When I click on OK the installation aborts. -- 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.
https://bugzilla.novell.com/show_bug.cgi?id=300694#c1 --- Comment #1 from Marco Michna <mmichna@novell.com> 2007-08-15 09:38:47 MST --- Created an attachment (id=157696) --> (https://bugzilla.novell.com/attachment.cgi?id=157696) screenshot of the error -- 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.
https://bugzilla.novell.com/show_bug.cgi?id=300694 Christoph Thiel <cthiel@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |cthiel@novell.com AssignedTo|coolo@novell.com |bk@novell.com -- 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.
https://bugzilla.novell.com/show_bug.cgi?id=300694#c2 --- Comment #2 from Marco Michna <mmichna@novell.com> 2007-08-15 10:12:07 MST --- JFYI: the mount command also fails with: --8<-- WARNING: Forced mount, unclean volume information is ignored. fuse: failed to access mountpoint /mnt/windows/C: No such file or directory FUSE mount point creation failed Unmounting /dev/sda1 () -->8-- The reason might be that there is no /mnt/windows/C After I created it by hand there only remains: --8<-- WARNING: Forced mount, unclean volume information is ignored. -->8-- But it doesnt change the fact that the installation aborts. -- 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.
https://bugzilla.novell.com/show_bug.cgi?id=300694#c3 Bernhard Kaindl <bk@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bk@novell.com AssignedTo|bk@novell.com |fehr@novell.com --- Comment #3 from Bernhard Kaindl <bk@novell.com> 2007-08-20 09:49:59 MST --- Hi Thomas, could it be that /mnt/windows/C was only created for vfat and ntfs but not now with ntfs-3g? This bug at least seems to suggest that. I will try to get ntfs-3g changed to mount also volumes which are scheduled for check (but then only mount them read-only, unless -oforce is used), but I do not know whether this will happen and if that will cover all possibilities of a mount of ntfs-3g failing. Thomas, could you either: a) switch back to fstype "ntfs" for ntfs-partitions b) tolerate an error from mounting partitions with ntfs-3g when they are mounted. (Note: ntfs-3g could be used somewhere outside of /mnt/windows, but as ntfs-3g currently same level permission support as FAT (only fixed for whole fs using mount flags), it's not desirable to use it seriously for system files) I think that b) would be most desirable to prevent the complete abort of the installation if an error mounting some windows NTFS partition fails. Having b) implemented after installation, in the installed system may also be desirable because that would allow to set the options, boot into windows, check the filesystem as described by the mount error which yast2 disk shows and boot back into Linux and not having to redo all mount options again. PS: Please remove "nls=utf8" from the ntfs-3g mount flags, it's ignored by ntfs-3g and replaced by the locale=en_US.UTF-8, which you already added. PPS: In bug 293429, coolo suggested to use fmask=133,dmask=022, so these should replace the umask=0002 which is currently in the default options string, because umask=0002 acts very different with ntfs-3g (default permissions are then 775 [rwxrwxr-x] instead of the default of 777, not 555 [r-xr-xr-x] instead of the default of 500 [r-x-------] as it is with ntfs). Having 644 for files and 755 for directories as caused by fmask=133,dmask=022 with ntfs-3g seems more desirable. Coolo also suggested: noauto,user, which I'd second. Then the NTFS windows partitions would not be mounted by default and then any error in mounting NTFS partitions would not occur at boot (or during installation) but when the user really wants to access them. Having many partitions mounted with ntfs-3g can -- 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.
https://bugzilla.novell.com/show_bug.cgi?id=300694#c4 Thomas Fehr <fehr@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |NEEDINFO Info Provider| |cthiel@novell.com --- Comment #4 from Thomas Fehr <fehr@novell.com> 2007-08-20 09:56:23 MST --- Coolo, need decision what to do with ntfs partitions. -- 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.
https://bugzilla.novell.com/show_bug.cgi?id=300694#c5 --- Comment #5 from Bernhard Kaindl <bk@novell.com> 2007-08-20 10:20:22 MST --- To continue my last comment: Having mounted many partitions mounted with ntfs-3g may also result in a bit more overhead than the in-kernel ntfs filesystem has because it creates a user space daemon per mount point, but OTOH, mounting my external 750GB Seagate FreeAgent Pro with 30.000 files (38% full) only takes ~150 ms after blockdev --flushbufs while mounting it with the kernel's ntfs takes ~350 ms, so on the time for mounting is lower, but the mount.ntfs-3g daemon shows 15MB VIRT, 1MB RES and 0.5M SHR in top, while after a 'find' over the full disk, it shows 20MB VIRT, 6.5MB RES and a few more K of SHR in top. -- 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.
https://bugzilla.novell.com/show_bug.cgi?id=300694#c6 Christoph Thiel <cthiel@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |ASSIGNED Info Provider|cthiel@novell.com | --- Comment #6 from Christoph Thiel <cthiel@novell.com> 2007-08-20 11:04:33 MST --- After talking to Thomas, I'd suggest to first try to fall-back to read-only mode, in case the mount fails. If we cannot implement in time, let's switch the default back to ntfs. -- 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.
https://bugzilla.novell.com/show_bug.cgi?id=300694 Christoph Thiel <cthiel@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|fehr@novell.com |bk@novell.com Status|ASSIGNED |NEW -- 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.
https://bugzilla.novell.com/show_bug.cgi?id=300694#c7 Thomas Fehr <fehr@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fehr@novell.com --- Comment #7 from Thomas Fehr <fehr@novell.com> 2007-08-20 11:24:39 MST --- Another possibility would be that libstorage retries an explicit read-only mount with ntfs-3g, when the normal rw-mount fails. If the read-only mount succeeds, we could add this fs with option "ro" to fstab which would at least make system startup succeed. Of course this only makes sense if a read-only mount would succeed in these cases where a read-write mount fails. Of course an automated fallback to read-only mount in ntfs-3g package would be preferable since then the fs would be mounted read-write automatically after the user fixed the fs inconsistency under Windows and reboots into Linux without need to do a change to fstab. BTW: I added "fmask=133,dmask=022" to ntfs default options. Removed "umask=0002" and "nls=utf8" from ntfs default 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.
https://bugzilla.novell.com/show_bug.cgi?id=300694#c8 Szabolcs Szakacsits <szaka@sienet.hu> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |szaka@sienet.hu --- Comment #8 from Szabolcs Szakacsits <szaka@sienet.hu> 2007-08-21 05:07:16 MST --- Hi! From NTFS-3G upstream: I think the fundamental problem here is that that the install/boot shouldn't stop if non OS critical file system can't be mounted. That is, trying to make NTFS mounted is not the right approach here, in my opinion. There can be many, different reasons why a file system is unmountable. NTFS-3G has extra sanity checks which are not included in ordinary file system drivers (i.e. it can detect unconfigured, unactivated, not correctly setup RAID, Dynamic Disks, etc). The "unclean volume" error is caused basically always by ntfsresize which is completely safe to ignore. Setting the NTFS volume flag dirty is used as a workaround for partition editors not doing correct NTFS partitioning. So, ntfsresize tricks Windows via the file system to fix the Windows partition, not the file system. The name of the 'force' mount option is also misleading. What it does in real is it ignores the file system dirty flag which was set by ntfsresize (see above) and it fixes/resets the NTFS journal file if needed. It's planned to ignore the otherwise unused "dirty flag" without a warning by default and use a new, more explanatory 'fix' mount option for the second and online repair cases. The driver already fixes silently minor corruptions what other drivers leave behind and this approach will be used more intensively in the future (ZFS also does online fsck, offline fsck is the past). -- 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.
https://bugzilla.novell.com/show_bug.cgi?id=300694#c9 --- Comment #9 from Thomas Fehr <fehr@novell.com> 2007-08-21 07:55:58 MST --- If behavior of ntfs-3g is not compatible with fstab semantics, I would advise to go back to old ntfs kernel driver which only mounts readonly but is at least able to do this reliably. -- 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.
https://bugzilla.novell.com/show_bug.cgi?id=300694#c10 --- Comment #10 from Szabolcs Szakacsits <szaka@sienet.hu> 2007-08-21 09:12:55 MST --- Thomas: would you please explain what you mean "ntfs-3g is not compatible with fstab semantics"? I'd really love to help but I seriously don't even understand what this issue has to do with ntfs-3g itself. Wouldn't you also abort if any FAT, ext3, etc partition would fail to mount/fsck? If not then why is NTFS handled differently? (I'm just interested, I've never met such drastic handling of non-critical mount failures.) If a volume is badly corrupted, or doesn't have the file system signature at all (wrong/changed device), or missing an important strip disk from a RAID, or a network server or removable media is not available when configured for boot time mount, etc then no driver can mount those non-existent file systems. Wouldn't it be more productive and user-friendly to continue and investigate/fix these issues when the OS is fully up instead of a total system failure? -- 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.
https://bugzilla.novell.com/show_bug.cgi?id=300694#c11 --- Comment #11 from Thomas Fehr <fehr@novell.com> 2007-08-21 09:46:22 MST --- If an entry is in fstab, it needs to be reliably mountable at system startup. Since this is not the case for ntfs-3g, I see not how we can use ntfs-3g for entries in fstab. Of course I also would abort if any FAT, ext3 whatever partition is not mountable, but so far such cases did not happen. So the problem with ntfs-3g is that it is currently NOT handled differently to all other filesystems. The real problem is not within YaST2, ignoring the mount failure for ntfs-3g would be easily doable (but I doubt ignoring return codes is really the way to go) if decision makers tell me to do so. But what is with the normal system boot. Depending on what the user did during his last windows session (and if ntfs is considered consistent or inconsistent by ntfs-3g) he will either have read-write access to the filesystem or no access at all. I do not think this is what users would expect. I understand that there are cases where ntfs-3g has valid reasons to refuse mounting read-write, but I would think in these cases it should simply mount read-only instead and report the reason for doing this on terminal and in via system log. Similar to the case where I do a "mount -tiso9660 /dev/cdrom /mnt" (forgetting the -r switch) and mount tells me that it mounts readonly, instead of failing the mount command completely. -- 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.
https://bugzilla.novell.com/show_bug.cgi?id=300694#c12 --- Comment #12 from Szabolcs Szakacsits <szaka@sienet.hu> 2007-08-21 10:41:00 MST --- Thanks, I see. You want the driver to mount read-only when the user expects read-write mount but that is refused. I'm sorry but this won't happen. (Of course the driver is yours, and you're encouraged to modify it to your liking.) Here is the current situation: 1. If a user asks read-write mount then he gets read-write mount or error. 2. If a user asks read-only mount then he gets read-only mount or error. If somebody wants to do what you want then he can make a script. Let's suppose now that ntfs-3g would do what you want. Then how would you satisfy people who want case 1? Using an option 'yes-i-really-want-only-read-write'? Isn't the 'rw' option is supposed to do that? The iso9600 case is a bit different, since there isn't read-write mount there. -- 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.
https://bugzilla.novell.com/show_bug.cgi?id=300694#c13 --- Comment #13 from Thomas Fehr <fehr@novell.com> 2007-08-21 10:49:25 MST --- I personally do not care much, lets see what the decision makers decide. -- 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.
https://bugzilla.novell.com/show_bug.cgi?id=300694#c14 Thomas Fehr <fehr@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |NEEDINFO Info Provider| |cthiel@novell.com --- Comment #14 from Thomas Fehr <fehr@novell.com> 2007-08-21 10:56:16 MST --- Christoph, what should be done? I would suggest to simply go back to old ntfs driver. -- 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.
https://bugzilla.novell.com/show_bug.cgi?id=300694#c15 --- Comment #15 from Bernhard Kaindl <bk@novell.com> 2007-08-21 11:21:35 MST --- Created an attachment (id=158806) --> (https://bugzilla.novell.com/attachment.cgi?id=158806) Patch to allow to mount dirty volumes read-only with -oro (without force) As far as I understood Szaka in private mail, it's no problem to mount dirty volumes read-only when the mount option ro is used (without force), and I believe that the attached patch does what he had in mind. On failing the mount when read-write-mode is not desirable for the fs state: Well, I do not specify "rw" as an mount option, and mount fails nonetheless. It would be easy to implement force the current behaviour when "rw" is specified. I think that I am at about 50% progress have an implementation for such fallback, the question is whether Szaka would accept it upstream if it comes with an option like --enable-readonly-mount-fallback option for configure.ac I think that it would be a pity to have forks (each patch that is not upstream is IMHO a fork) -- 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.
https://bugzilla.novell.com/show_bug.cgi?id=300694#c16 Christoph Thiel <cthiel@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |ASSIGNED Info Provider|cthiel@novell.com | --- Comment #16 from Christoph Thiel <cthiel@novell.com> 2007-08-21 11:28:58 MST --- I'd definitely vote/go for Bernhards approach in comment #15. -- 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.
https://bugzilla.novell.com/show_bug.cgi?id=300694#c17 --- Comment #17 from Thomas Fehr <fehr@novell.com> 2007-08-21 11:36:40 MST --- Have fun hacking boot.localfs to specially handle ntfs-3g. That patch alone does not help when the ntfs-3g fstab entries are mounted in boot.localfs. -- 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.
https://bugzilla.novell.com/show_bug.cgi?id=300694#c18 --- Comment #18 from Thomas Fehr <fehr@novell.com> 2007-08-21 11:41:36 MST --- Maybe best would be to create a boot.ntfs-3g that handles mounting of the ntfs-3g entries from fstab and add a "nontfs-3g" to -t option in boot.localfs. So the handling of ntfs-3g would at least be in a central plase without unnecessary messing up boot.localfs. /etc/init.d/boot.ntfs-3g should then be part of ntfs-3g RPM. -- 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.
https://bugzilla.novell.com/show_bug.cgi?id=300694#c19 --- Comment #19 from Bernhard Kaindl <bk@novell.com> 2007-08-21 12:06:58 MST --- Created an attachment (id=158813) --> (https://bugzilla.novell.com/attachment.cgi?id=158813) Patch to automatically fall back to read-only mount if volume is dirty
Maybe best would be to create a boot.ntfs-3g that handles mounting of the ntfs-3g entries from fstab and add a "nontfs-3g" to -t option in boot.localfs.
So the handling of ntfs-3g would at least be in a central plase without unnecessary messing up boot.localfs. /etc/init.d/boot.ntfs-3g should then be part of ntfs-3g RPM.
Yes, I thought of this already to be sure that ntfs-3g does not cause any problems during system boot. Using 10.2, I tested what happens when a system is booted with a dirty NTFS volume in /etc/fstab after ntfs-3g fails to mount it: In this test the other non-root filesystem (/home) was mounted as usual (it was mounted before the ntfs volume but I think mount does not abort mounting when one fstab entry fails) and it printed this to the console Volume is scheduled for check. Please boot into Windows TWICE, or use the 'force' mount option. For example type on the command line: mount -t ntfs-3g /ntfs.image /media/ntfs -o force Or add the option to the relevant row in the /etc/fstab file: /ntfs.image /media/ntfs ntfs-3g defaults,force 0 0 boot.localfs ended with status "failed" but otherwise the system came up nicely. AFAICS, the implications which a separate ntfs-3g mount script would have are: 1) There would not even be an attempt to mount ntfs-3g volumes at boot if ntfs-3g is not installed, no error message would be seen. 2) The 'nontfs-3g' in /etc/init.d/boot.localfs would also cause that somebody who does not install our ntfs-3g rpm but installs ntfs-3g from source would have to also install a similar mount script or remove the nontfs-3g from /etc/init.d/boot.localfs 3) Mount failures of ntfs-3g would not be shown as an boot failure in boot.localfs but as one in the ntfs-3g mount script. Implication 1) may be desirable or not (maybe we should give an error during boot when ntfs-3g is in fstab but ntfs-3g is not installed), Implication 2) is likely bearable and 3) is likely nice, but I do not see a a pressing need from any of those. While this does not exclude the possiblity of a failed ntfs-3g mount at boot, the new attachment of this comment has the first working patch to fall back to an read-only mount if the NTFS volume is dirty. The previous patch to allow to mount a dirty volume with "ro" (without force) is part of this patch because it builds on it. I think I am also half-way done to implement that specifying "rw" explicitly, not implicitly as part of the "defaults" mount option causes ntfs-3g to mount read-write or fail. -- 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.
https://bugzilla.novell.com/show_bug.cgi?id=300694#c20 --- Comment #20 from Bernhard Kaindl <bk@novell.com> 2007-08-21 17:53:58 MST --- Created an attachment (id=158857) --> (https://bugzilla.novell.com/attachment.cgi?id=158857) [PATCH] If the new mount option "rwonly" is not given, automatically fall back to read-only mount if volume is dirty The attached patch implements a new mount option which I called "rwonly", which, if given, disables the fallback to a read-only mount if the volume is dirty and makes mount fail in this case, which is the current behaviour of ntfs-3g. Otherwise, if rwonly is not given, it works like the previous patch, which adds the fall-back to read-only mode if the volume is given (and also allows to manually use the "ro" option to force read-only mode wihtout using force on a dirty volume. This patch does not yet log mount errors to syslog(3), but if any mount error happens during system boot, it is found /var/log/boot.msg: Mounting local file systems... proc on /proc type proc (rw) sysfs on /sys type sysfs (rw) debugfs on /sys/kernel/debug type debugfs (rw) udev on /dev type tmpfs (rw) devpts on /dev/pts type devpts (rw,mode=0620,gid=5) /dev/sda6 on /home type reiserfs (rw) Volume is scheduled for check. Please boot into Windows TWICE, or use the 'force' mount option. For example type on the command line: mount -t ntfs-3g /ntfs.image /media/ntfs -o force Or add the option to the relevant row in the /etc/fstab file: /ntfs.image /media/ntfs ntfs-3g defaults,force 0 0 failed<notice>'boot.localfs start' exits with status 0 <notice>boot.apparmor start Loading AppArmor module done BTW, a colleague told me that hfsplus has already a such fallback from read-write to read-only -- from fs/hfsplus/super.c: if (!(vhdr->attributes & cpu_to_be32(HFSPLUS_VOL_UNMNT))) { printk("hfs: Filesystem was not cleanly unmounted, " "running fsck.hfsplus is recommended. mounting read-only.\n"); sb->s_flags |= MS_RDONLY; } else if (sbi->flags & HFSPLUS_SB_FORCE) { /* nothing */ } else if (vhdr->attributes & cpu_to_be32(HFSPLUS_VOL_SOFTLOCK)) { printk("hfs: Filesystem is marked locked, mounting read-only.\n"); sb->s_flags |= MS_RDONLY; } else if (vhdr->attributes & cpu_to_be32(HFSPLUS_VOL_JOURNALED)) { printk("hfs: write access to a jounaled filesystem is not supported, " "use the force option at your own risk, mounting read-only.\n"); sb->s_flags |= MS_RDONLY; } As Szaka prefers the rw-only behaviour and as I'd find it handy to be able to change the default mount flags of ntfs-3g in system-wide and user-specifc config files, and if he (or we) like the idea, I'd also like to implement those. In Szaka's upstream code, the defaults could then implement rw-only by default and we or other admins could specify e.g. 'mount_dirty_ro' (which is what we want) and e.g. 'fmask=133,dmask=022' using /etc/ntfs3grc (and ~/.ntfs3grc for users which do not like the settings in /etc) so that a user or admin who simply mounts an ntfs-filesystem gets safer defaults than the default 777 permissions and if that would be accepted by Skzaka, we would not have to patch ntfs-3g but only need to provide config files. -- 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.
https://bugzilla.novell.com/show_bug.cgi?id=300694#c21 --- Comment #21 from Szabolcs Szakacsits <szaka@sienet.hu> 2007-08-22 14:26:30 MST --- There is a misunderstanding here. I was talking about the general error handling behavior, i.e. I thought you __always__ want to mount 'ro' if 'rw' mount fails. But it seems, this issue is only about the "dirty" volume handling. That case I commented at https://bugzilla.novell.com/show_bug.cgi?id=300694#c8 That is: ==> The "unclean volume" error is caused basically always by ntfsresize which is completely safe to ignore. <== Hence this is fixed in upstream accordingly by removing the useless code. This is also what ext2, ext3, ext4, xfs and reiserfs do in similar case. Patch is at: http://mercurial.creo.hu/repos/ntfs-3g-hg/?rev/c94ada60852b When the dirty flag check was added many thousands years ago, we didn't know the real "dirtiness" is indicated in the NTFS logfile. Thanks. -- 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.
https://bugzilla.novell.com/show_bug.cgi?id=300694#c23 Thomas Fehr <fehr@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dkukawka@novell.com --- Comment #23 from Thomas Fehr <fehr@novell.com> 2007-08-30 02:52:10 MST --- *** Bug 306029 has been marked as a duplicate of this bug. *** https://bugzilla.novell.com/show_bug.cgi?id=306029 -- 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.
https://bugzilla.novell.com/show_bug.cgi?id=300694#c24 Bernhard Kaindl <bk@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |RESOLVED Info Provider|bk@novell.com | Resolution| |FIXED --- Comment #24 from Bernhard Kaindl <bk@novell.com> 2007-08-31 05:40:23 MST --- @Szaka: Many thanks! The new release with the check removed is in our repo now. @cthiel: Yes, this bug has been adressed in an upstream and is in STABLE now. -- 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.
participants (1)
-
bugzilla_noreply＠novell.com