Short description: After ntfsresize of a Windows 8.1 volume, Windows 8.1 doesn't automatically repair the resized volume like Windows 7 does. And ntfsresize continues to suggest chkdsk needs to be used. Manually running Windows 8.1 Startup Repair or chkdsk /f fixes the problem. Concern is mainly for GUI installers leveraging ntfsresize. They don't inform the user they need to manually run either chkdsk /f or run startup repair. Version-Release number of selected component (if applicable): ntfs-3g-2014.2.15-4.fc21.x86_64 How reproducible: Always Steps to Reproduce: 1. Default Windows 8.1 installation 2. Boot Fedora-Live-Workstation-x86_64-21-20140826.iso 3. Check the partition map with fdisk -l Device Boot Start End Sectors Size Id Type /dev/sda1 * 2048 718847 716800 350M 7 HPFS/NTFS/exFAT /dev/sda2 718848 178255871 177537024 84.7G 7 HPFS/NTFS/exFAT 4. Determine that the filesystem state is OK prior to the resize attempt; confirm 177537024 sectors from fdisk equals "current device size" of 90898956288 bytes from ntfsresize. # ntfsresize -c /dev/sda2 # ntfsresize -i /dev/sda2 ntfsresize v2014.2.15 (libntfs-3g) Device name : /dev/sda2 NTFS volume version: 3.1 Cluster size : 4096 bytes Current volume size: 90898952704 bytes (90899 MB) Current device size: 90898956288 bytes (90899 MB) Checking filesystem consistency ... 100.00 percent completed Accounting clusters ... Space in use : 9296 MB (10.2%) Collecting resizing constraints ... You might resize at 9295036416 bytes or 9296 MB (freeing 81603 MB). Please make a test run using both the -n and -s options before real resizing! # ntfsfix -n /dev/sda2 Mounting volume... OK Processing of $MFT and $MFTMirr completed successfully. Checking the alternate boot sector... OK NTFS volume version is 3.1. NTFS partition /dev/sda2 was processed successfully. 4. After a dry run with -n -s, actually do the resize. # ntfsresize -s 45G /dev/sda2 ntfsresize v2014.2.15 (libntfs-3g) Device name : /dev/sda2 NTFS volume version: 3.1 Cluster size : 4096 bytes Current volume size: 90898952704 bytes (90899 MB) Current device size: 90898956288 bytes (90899 MB) New volume size : 45000000000 bytes (45000 MB) Checking filesystem consistency ... 100.00 percent completed Accounting clusters ... Space in use : 9296 MB (10.2%) Collecting resizing constraints ... Needed relocations : 0 (0 MB) WARNING: Every sanity check passed and only the dangerous operations left. Make sure that important data has been backed up! Power outage or computer crash may result major data loss! Are you sure you want to proceed (y/[n])? y Schedule chkdsk for NTFS consistency check at Windows boot time ... Resetting $LogFile ... (this might take a while) Updating $BadClust file ... Updating $Bitmap file ... Updating Boot record ... Syncing device ... Successfully resized NTFS on device '/dev/sda2'. You can go on to shrink the device for example with Linux fdisk. IMPORTANT: When recreating the partition, make sure that you 1) create it at the same disk sector (use sector as the unit!) 2) create it with the same partition type (usually 7, HPFS/NTFS) 3) do not make it smaller than the new NTFS filesystem size 4) set the bootable flag for the partition if it existed before Otherwise you won't be able to access NTFS or can't boot from the disk! If you make a mistake and don't have a partition table backup then you can recover the partition table by TestDisk or Parted's rescue mode. 5. Get info on the volume # ntfsresize -i /dev/sda2 ntfsresize v2014.2.15 (libntfs-3g) ERROR: Volume is scheduled for check. Run chkdsk /f and please try again, or see option -f. # ntfsfix -n /dev/sda2 Mounting volume... OK Processing of $MFT and $MFTMirr completed successfully. Checking the alternate boot sector... BAD Error: Failed to fix the alternate boot sector 6. Use fdisk to set the partition to match volume size. /dev/sda2 718848 88610815 87891968 41.9G 7 HPFS/NTFS/exFAT 7. Same ntfsresize and ntfsfix results at this point. Reboot Windows8. No automatic repair occurs (like Windows 7) or file system errors reported. I do get to the desktop. Reboot again, same result. 8. Reboot Fedora Live install media # ntfsresize -i /dev/sda2 ntfsresize v2014.2.15 (libntfs-3g) ERROR: Volume is scheduled for check. Run chkdsk /f and please try again, or see option -f. # ntfsfix -n /dev/sda2 Mounting volume... OK Processing of $MFT and $MFTMirr completed successfully. Checking the alternate boot sector... OK NTFS volume version is 3.1. NTFS partition /dev/sda2 was processed successfully. Actual results: Windows 8 doesn't see a problem on its own when starting up after an ntfsresize. But ntfsresize itself sees the volume check flag still set and spits out an error. A manual repair by Windows resolves the problem. Expected results: Windows 8 clears the volume check flag. The question is, does ntfsresize set the correct flag on Window 8 NTFS volumes? (Is it possible there's a new one that differs from Windows 7?) If it's not cleared is there any harm down the road? Or must the user be vigilantly informed in GUI programs that they need to manually intervene and chkdsk /f? Additional info:
"The question is, does ntfsresize set the correct flag on Window 8 NTFS volumes? (Is it possible there's a new one that differs from Windows 7?)" Possible, but unlikely. Windows 8 just cannot imagine a flag could pop out of nowhere. "If it's not cleared is there any harm down the road?" No danger related to the flag being set. The danger stems from the resizing, so doing a chkdsk is a safety measure. For example, a backup boot sector should be copied to the last sector of the resized partition, but if an approximate new partition size is requested (such as in "ntfsresize -s 45G /dev/sda2"), ntfsresize cannot know for sure where the future last sector will be, and this is left for chkdsk to repair. After the Windows 8 reboot, does "ntfsfix -n" report a bad backup boot sector ? This will show whether chkdsk was run. The backup boot sector is a minor concern as it is only used when the normal boot sector has been damaged, and this issue can be avoided by telling ntfsresize the exact future size of the partition (a byte count multiple of the sector size), or by starting ntfsfix after the partition is created.
After Windows 8 reboot, "ntfsfix -n" does not report a bad backup boot sector, but "ntfsresize -i" still sees a volume check flag set. Windows 7 fixes the backup boot sector, and unsets the volume check flag at the next boot. While Windows 8 only fixes the backup boot sector.
If "ntfsfix -n" reports a bad backup boot sector before the Windows 8 reboot (but after the new partition table has been written), and it does not after the reboot, then Windows 8 has made a check (probably through a minimal chkdsk on the mounted partition) and there is nothing to worry about. As Windows behavior may change in the future, GUIs should nevertheless recommend starting chkdsk manually.
This message is a reminder that Fedora 21 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 21. 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 EOL if it remains open with a Fedora 'version' of '21'. 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. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 21 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 change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. 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.
Fedora 21 changed to end-of-life (EOL) status on 2015-12-01. Fedora 21 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. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.