https://bugzilla.novell.com/show_bug.cgi?id=309074#c16 --- Comment #16 from Szabolcs Szakacsits <szaka@sienet.hu> 2007-10-10 10:29:41 MST --- Hi, Here is my longer explanation I sent to Bernhard some time ago: -----------------------------------------------------------------------> When Windows is hibernated or the journal file is in use then that means that the data on the disk is inconsistent and it's from sometime in the mixed past. Some examples: 1) User deletes a lot of files on Windows and when he boots Linux he finds that the files are still there. 2) User copies a lot of valuable files on Windows and when he boots Linux he finds that he lost all his recent and even the old files! 3) User does very complex file manipulation editing and when he boots Linux he finds that his files are totally messed up and corrupted. The case 1) is not so bad, users typically find it funny but they can get __really__ histerical, desparate, angry, threatening when 2) or 3) happens and they make very loud noise how unreliable Linux/SUSE/NTFS-3G is and that it lost, removed, deleted, trashed all their data. Some people (old, young, computer illetarate, normal, etc) can be so upset that they don't even boot Windows anymore but reformat the drive thus deleting their valuable data themself (though this may sound very funny but please believe me, not for them!). However when mount is refused then they __immediately__ notice that something is not correct and they check the reason. They read it, follow it and think how smart Linux is that it can detect that they didn't shutdown Windows properly. And they end up being happy. These are the real, human reasons I think SUSE boot should just ignore the mount failure and keep going. I think not mounting is a much better option than presenting the user an inconsistent, old, meaningless file system state which could highly confuse, scare, disappoint, mislead them. Please note, that we are talking here only about two cases when we successfully detected for sure that we can not present the user a valid file system state. In all other cases the driver do its best to mount the file system. The journal case could be solved (read-write mount) in the future if we knew the full NTFS journaling specification. But we don't know it. The hibernation case is impossible to solve because that would require a dehibernation by a full Windows OS on Linux then a clean Windows shutdown with all currently running user applications. The only choice for read-write mount is the removal of the Windows hibernation file which means the user will lose all his in-memory data saved into the hibernation file. <-------------------------------------------------------------------------- Btw, users are reporting they can't write to NTFS in 10.3 but typically it's because they don't have write access as ordinary user without fstab modification or ntfs-3g wasn't installed, etc. Regards, Szaka -- NTFS-3G Lead Developer: http://ntfs-3g.org -- 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.