Red Hat Bugzilla – Bug 859373
Danger in dual booting Windows 8 and Linux
Last modified: 2012-12-20 11:02:22 EST
Description of problem:
When using the "fast restart" feature, Windows 8 uses cached metadata saved at previous shutdown instead of what is actually on disk. This may occur on any partition of internal disks mounted by Windows (not limited to the Windows system partition).
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Work on Windows 8, then shutdown with fast restart enabled.
2. Boot into Linux through grub.
3. Create some new files on an internal partition which was mounted by Windows, and leave Linux
4. Reboot into Windows 8 and check the files created by Linux
The files created by Linux may be missing, and new files created on Windows may overwrite them.
The files created by Linux should be visible.
This apparently only happens when :
a) the fast restart feature of Windows 8 is enabled
b) Windows 8 is closed using the "Shut down" button (it does not happen when using the "Restart" button)
c) the dual booting into Linux is done though grub (it does not happen when booting into Linux through the Windows multiboot feature).
Starting chkdsk when entering Windows 8 drops the cached metadata and restores the state left by Linux.
The only known work around is to disable the fast restart feature (see http://jp-andre.pagesperso-orange.fr/advanced-ntfs-3g.html#windows8 )
Jean-Pierre, since the only known workaround is to disable the fast restart feature from within Windows 8, what do you want me to do here? We can document this in our release notes, but if you can't fix it... :)
Well, Tom, this was intended to have to issue documented in a place where users might look at, rather than asking you to do some special thing. I will take care of having it documented in the manual.
Okay, thanks. :) I wasn't sure what you were asking for me to do here.
This has been referenced in the Fedora 18 release notes and in the Common Bugs page (https://fedoraproject.org/wiki/Common_F18_bugs#win8-fast-restart). Marking this bug closed.
I believe CANTFIX resolution is more appropriate, it says that even though we documented the issue, it still persists and we can't really do much about it. (Otherwise someone could see just the "closed fixed" status and assume this has been fixed somehow). Changing resolution and also component back to ntfs-3g.
However, I believe there could be ways to improve the situation. We could detect whether Win 8 is present on the computer, and if we mount NTFS partition in such case, we could force chkdsk to be run on the next Windows boot. That would make sure user data are not lost. The question is whether we can do this only if fast-restart feature is turned on (whether we can detect that somehow), otherwise this solution could be a bit annoying.
Another solution is that the installer could try to disable fast-restart feature if it detects Win 8 (again, if this is possible at all).
These are wild guesses, I'm not the expert here.
CANTFIX if probably appropriate to mean that mounting a file system not sync'ed by Windows cannot be prevented from being dangerous (hibernation and fast restart on Windows 8 imply not sync'ed to disk).
Now, I think it is possible to detect the dangerous situations and refuse to mount with *future* ntfs-3g versions. This might still be unpleasant to users. You may apply the following couple of patches for that :
first : http://ntfs-3g.git.sourceforge.net/git/gitweb.cgi?p=ntfs-3g/ntfs-3g;a=commit;h=4d0b9163c9ef1f0cdbbf533317b291220c7fd1c7
then : http://ntfs-3g.git.sourceforge.net/git/gitweb.cgi?p=ntfs-3g/ntfs-3g;a=commit;h=559270a8f67c77a7ce51246c23d2b2837bcff0c9
I have tested these patches, and they are scheduled for next ntfs-3g release.
Jean-Pierre, that is great news. Refusing to mount is another great option how to make sure user data is safe. Ideally the high-level applications (Nautilus etc) could even display some reasonable error message.
Reopening this bug to track the progress.
ntfs-3g-2012.1.15-4.fc17 has been submitted as an update for Fedora 17.
ntfs-3g-2012.1.15-4.fc18 has been submitted as an update for Fedora 18.
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing ntfs-3g-2012.1.15-4.fc18'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).
ntfs-3g-2012.1.15-5.fc17 has been submitted as an update for Fedora 17.
ntfs-3g-2012.1.15-5.fc18 has been submitted as an update for Fedora 18.
ntfs-3g-2012.1.15-4.fc17 has been pushed to the Fedora 17 obsolete repository. If problems still persist, please make note of it in this bug report.