https://bugzilla.novell.com/show_bug.cgi?id=309074#c16
--- Comment #16 from Szabolcs Szakacsits 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.