Bug 790666

Summary: NTFS partitions don't unmount cleanly on shutdown
Product: [Fedora] Fedora Reporter: Matt Chan <talcite>
Component: ntfs-3gAssignee: Tom "spot" Callaway <tcallawa>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 16CC: ccecchi, jean-pierre.andre, talcite, tbzatek, tcallawa
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-02-13 23:11:42 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Matt Chan 2012-02-15 06:30:16 UTC
Description of problem:
NTFS partitions mounted through nautilus don't unmount cleanly on shutdown. Windows fails to see some of the directories modified and it creates filesystem corruption.

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. Mount NTFS partition through nautilus
2. Change some files on partition
3. Shutdown system
  
Actual results:
Windows reports filesystem errors on startup

Expected results:
The filesystem should have no errors.

Additional info:
I'm using windows 7 in dual-boot.

Comment 1 Tomáš Bžatek 2012-02-15 12:52:52 UTC
Are you using ntfs-3g or the old kernel driver? I guess consistency check on Windows start is a design issue anyway.

Comment 2 Matt Chan 2012-02-15 13:07:45 UTC
I'm not sure. How do I check which driver is in use?

If it were only the consistency check, I wouldn't mind. But the consistency check shows errors on files that I just modified in Fedora. I'm guessing that there's a write buffer that doesn't get flushed since it doesn't unmount cleanly?

Comment 3 Tomáš Bžatek 2012-02-15 13:47:44 UTC
Simple `mount` command would print all the information.

Comment 4 Matt Chan 2012-02-15 14:16:30 UTC
Hi Tomáš, 

`mount` prints this:

...
fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime)
gvfs-fuse-daemon on /home/mattchan/.gvfs type fuse.gvfs-fuse-daemon (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)
/dev/sda2 on /media/Windows7_OS type fuseblk (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096)


It looks like it's mounted with fuse?

Comment 5 Tomáš Bžatek 2012-02-16 16:55:05 UTC
Thanks, so it's ntfs-3g after all. Reassigning.

Comment 6 Jean-Pierre André 2012-02-17 07:28:05 UTC
What ntfs-3g version are you using ? (type "ntfs-3g --help")

> NTFS partitions mounted through nautilus don't unmount cleanly on shutdown.

On what kind of device are your partitions stored ?

Was your Windows 7 hibernated when you started ntfs-3g ?

Do allow enough time for the device to be synced after you made modifications and before you shut down ? (Note : umount does not wait, this is intentional).

Comment 7 Matt Chan 2012-02-17 08:00:36 UTC
Hi Jean-Pierre,

My NTFS-3g ver output is:

$ ntfs-3g --help

ntfs-3g 2011.4.12 integrated FUSE 27 - Third Generation NTFS Driver
		Configuration type 1, XATTRS are on, POSIX ACLS are off
...

I'm storing my partitions on a regular HDD.

Windows 7 was hibernated. Is that an unsupported use-case?

I think I'm allowing enough time for sync. There's usually about a minute between the time I write the change and shutdown?

Thanks,
Matt

Comment 8 Jean-Pierre André 2012-02-17 08:33:43 UTC
> Windows 7 was hibernated. Is that an unsupported use-case?

Yes, definitely. When restarting from hibernation, Windows uses its own cached data without checking whether the stored data has changed in the meantime.

From ntfs-3g 2012.1.15AR.1 ntfs-3g checks at mount time whether Windows 7 was hibernated.

Comment 9 Matt Chan 2012-02-17 08:48:02 UTC
Ok. Thanks for the heads-up. 

Can we make sure FUSE/nautilus will handle the warning and pass it to the user?

Matt

Comment 10 Jean-Pierre André 2012-02-17 10:46:38 UTC
> Can we make sure FUSE/nautilus will handle the warning and pass it to the user?

You will not be able to mount the Windows system partition (except by forced mount). If it not the system partition, and you do not try to mount the system partition, ntfs-3g cannot know, and nobody will tell you.

Comment 11 Fedora End Of Life 2013-01-16 19:17:26 UTC
This message is a reminder that Fedora 16 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 16. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '16'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 16's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 16 is end of life. If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora, you are encouraged to click on 
"Clone This Bug" and open it against that version of Fedora.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 12 Fedora End Of Life 2013-02-13 23:11:46 UTC
Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.