Bug 735612
| Summary: | ntfsprogs does not provide fsck.ntfs | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Laurence Smart <mail> | ||||
| Component: | ntfsprogs | Assignee: | Tom "spot" Callaway <tcallawa> | ||||
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | low | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 15 | CC: | eb30750, fedora, maurizio.antillon, tcallawa | ||||
| Target Milestone: | --- | Keywords: | Reopened | ||||
| Target Release: | --- | ||||||
| Hardware: | All | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | ntfs-3g-2011.4.12-5.fc16 | Doc Type: | Bug Fix | ||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2011-09-20 23:55:43 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
|
Description
Laurence Smart
2011-09-04 05:15:16 UTC
This is still an issue on FE-15. The suggested fix to add a link did not work for me. [root@BRSINC-01 home]# fsck.ntfs /dev/sdb1 bash: fsck.ntfs: command not found... [root@BRSINC-01 home]# [root@BRSINC-01 home]# fsck -t ntfs /dev/sdb1 fsck from util-linux 2.19.1 fsck: fsck.ntfs: not found fsck: Error 2 while executing fsck.ntfs for /dev/sdb1 [root@BRSINC-01 home]# [root@BRSINC-01 home]# yum list | grep ntfs ntfs-3g.x86_64 2:2011.4.12-3.fc15 @fedora ntfsprogs.x86_64 2:2011.4.12-3.fc15 @fedora ntfs-3g.i686 2:2011.4.12-3.fc15 fedora ntfs-3g-devel.i686 2:2011.4.12-3.fc15 fedora ntfs-3g-devel.x86_64 2:2011.4.12-3.fc15 fedora ntfs-config.x86_64 1.0.1-13.fc15 fedora [root@BRSINC-01 home]# [root@BRSINC-01 home]# ln -s /bin/ntfsck /sbin/mkfs.ntfs ln: failed to create symbolic link `/sbin/mkfs.ntfs': File exists [root@BRSINC-01 home]# [root@BRSINC-01 home]# ls -l /sbin/*.ntfs lrwxrwxrwx. 1 root root 12 Jul 21 22:24 /sbin/mkfs.ntfs -> /sbin/mkntfs lrwxrwxrwx. 1 root root 13 Jul 21 22:24 /sbin/mount.ntfs -> mount.ntfs-3g To be completely nitpicky, there is no "fsck" for NTFS filesystems. The closest thing that I am aware of is "ntfsfix", but that's not really a fsck either, which is why I don't have it symlinked to fsck.ntfs. If you want to manually make that symlink, go nuts, but I'd rather not do that by default. Those who have external USB disks for backup, etc. tend to use NTFS disk formatting since it is a "neutral" format where data can be recovered by either Linux or Windows. I use Linux but for the most part use NTFS for my backup or off line data storage. It would be nice to have the capability to run a disk check on these NTFS drives from Linux. Additionally, there is more disk recovery software for NTFS as well as professional recovery services available for NTFS should one ever need it. Some people, but not all, value their data and simply could not afford to lose it. A really good backup strategy is to have 2 external USB drives one formatted with linux and the other as NTFS. NTFSFIX is not the answer. Hi Paul, The "fix" didn't work for you because you tried to link mkfs.ntfs instead of fsck.ntfs. Hi Tom, Appreciate your perspective. If we ship ntfsck as a part of ntfsprogs, then why not link it too, so that at least fsck doesn't bork? If people want to use ntfsck (even if it does nothing) then it might be nice for fsck to do the right thing. And if it really is completely useless, then why ship ntfsck at all? Or maybe we should patch fsck to error if trying to fsck an ntfs volume, rather than trying to run fsck.ntfs and failing (even though the ntfsck tool exists). Seems to me that if people want to run fsck against an ntfs formatted partition, and ntfsck is installed, then the link should be there just like it is for fsck.msdos and fsck.fat32 (which I'm guessing are probably as equally useless?), or fsck should call the user an idiot for trying to check an ntfs formatted drive. -c Just noticed the "fix" from OP is wrong (which is why Paul got it wrong). Should be: ln -s /bin/ntfsck /sbin/fsck.ntfs -c I reinstalled ntfsprogs and linked accordingly. ln -s /bin/ntfsck /sbin/fsck.ntfs (I previously followed the instructions that the bug reporter stated in his comments that worked for him though I did notice the mkfs looked suspicious) When attempting to run fsck on ntfs I experienced these errors. fsck -t ntfs /dev/sdb1 fsck from util-linux 2.19.1 Boot sector: Bad NTFS magic. Warning... fsck.ntfs for device /dev/sdb1 exited with signal 11. This takes me back to why I reported this bug in the first place. When using the graphical disk management tool, "Disk Utility", I attempted to perform a file system check on an ntfs filesystem and the error "file system is not clean" was returned. So maybe Disk Utility has an ntfs chkdsk incorporated into it. Since neither of the programs work on ntfs there appears to be a more serious problem altogether. Sorry, I completely overlooked the existence /bin/ntfsck for some reason, I was remembering the old ntfsprogs where there wasn't one. I'll push an update that creates the symlink. ntfs-3g-2011.4.12-4.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/ntfs-3g-2011.4.12-4.fc15 ntfs-3g-2011.4.12-4.el6 has been submitted as an update for Fedora EPEL 6. https://admin.fedoraproject.org/updates/ntfs-3g-2011.4.12-4.el6 ntfs-3g-2011.4.12-4.el5 has been submitted as an update for Fedora EPEL 5. https://admin.fedoraproject.org/updates/ntfs-3g-2011.4.12-4.el5 ntfs-3g-2011.4.12-4.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/ntfs-3g-2011.4.12-4.fc16 ntfs-3g-2011.4.12-4.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/ntfs-3g-2011.4.12-4.fc14 Superstar, thanks Tom :-) -c Thanks for the great work Tom. Package ntfs-3g-2011.4.12-4.fc16: * should fix your issue, * was pushed to the Fedora 16 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing ntfs-3g-2011.4.12-4.fc16' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/ntfs-3g-2011.4.12-4.fc16 then log in and leave karma (feedback). I was able to install this version. Nothing available for fc16. "ntfs-3g.x86_64 2:2011.4.12-4.fc15 @updates-testing" This version does not work [root@BRSINC-01 EB30750]# fsck -ntfs /dev/sbd1 fsck from util-linux 2.19.1 fsck: fsck.fs: not found fsck: Error 2 while executing fsck.fs for /dev/sbd1 Hi Paul, Before you go blaming the update (just yet), is "fsck -ntfs" the right command to run? Try just: # fsck /dev/sbd1 It should automatically run "fsck.ntfs" (the point of this bug report). Note the error you are getting is: fsck.fs not found I don't think that there is an "fsck.fs" command. Hi Tom, Just tried the update, but I think you meant to put in ntfsprogs not ntfs-3g in comment 15 :-) # su -c 'yum update --enablerepo=updates-testing ntfsprogs' Anyway, I tried the update, but the link is broken. It's pointing to /ntfsck instead of /sbin/ntfsck. # ls -l /sbin/fsck.ntfs /sbin/fsck.ntfs -> ../ntfsck Should one of these I'm guessing: /sbin/fsck.ntfs -> ../bin/ntfsck /sbin/fsck.ntfs -> /bin/ntfsck Simple patch to your updates-testing spec attached. Cheers, -c Created attachment 522629 [details]
Fix link url in ntgs-3g spec file for ntfs.fsck
(In reply to comment #18) > Created attachment 522629 [details] > Fix link url in ntgs-3g spec file for ntfs.fsck So embarrassing! Thanks for this fix, a new round of updates incoming. ntfs-3g-2011.4.12-5.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/ntfs-3g-2011.4.12-5.fc16 ntfs-3g-2011.4.12-5.el5 has been submitted as an update for Fedora EPEL 5. https://admin.fedoraproject.org/updates/ntfs-3g-2011.4.12-5.el5 ntfs-3g-2011.4.12-5.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/ntfs-3g-2011.4.12-5.fc14 ntfs-3g-2011.4.12-5.el6 has been submitted as an update for Fedora EPEL 6. https://admin.fedoraproject.org/updates/ntfs-3g-2011.4.12-5.el6 ntfs-3g-2011.4.12-5.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/ntfs-3g-2011.4.12-5.fc15 Reseults from testing fsck ntfs with a unmounted external SATA disk connected the -ntfs option does not translate [root@BRSINC-01 EB30750]# fsck -ntfs /dev/sbd1 fsck from util-linux 2.19.1 fsck: fsck.fs: not found fsck: Error 2 while executing fsck.fs for /dev/sbd1 Looks like it executed but as stated earlier there are more serious problems with checking NTFS volumes using fsck [root@BRSINC-01 EB30750]# fsck.ntfs /dev/sdb1 Unsupported: replay_log() Unsupported: check_volume() Checking 34045 MFT records. Unsupported cases found. installed version [root@BRSINC-01 EB30750]# yum list | grep ntfs-3g ntfs-3g.x86_64 2:2011.4.12-5.fc15 @updates-testing First of all, your initial attempt to use fsck is syntactically wrong. If you want to force a filesystem type, use: fsck -t ntfs "fsck -ntfs" is just not valid syntax, and the "fsck.fs not found" error is a result of fsck trying to figure out what you're telling it and failing. When you manually invoke fsck.ntfs (which fsck -t ntfs would do as well), you discover basically what I was trying to say before: the ntfsck tool doesn't really do very much. All I did was apply fixes from upstream so that it doesn't outright segfault anymore. Hi Paul, Tom is right, I mentioned that syntax issue back in comment 17 in a reply. This bug report is only for the linking issue - if you wanted to create a separate bug report for the error you get when you run it, you can :-) However, as Tom said I think it will just get closed "will not fix" because it's an upstream issue and something Fedora can't fix. Better yet would be to put in a bug report upstream and ask the ntfs3g developers why it happens. Then we can link to the upstream bug report in your Fedora bug. You might also want to look at some other tools like ntfsfix, which Tom also mentioned. At the end of the day though, NTFS is not a native Linux file system so there are going to be tradeoffs/issues. For example, NTFS does not respect POSIX file system permissions, so using it as a backup in untarred files is probably not going to be great when it comes time to restore. In addition, relying on a non-native file system for your Linux backups also might bite you down the track. If it were for my backups, I would be using a native file system to reduce the risk of things going wrong. Separate partitions (and file systems) on a backup drive for Linux and Windows might be the way to go. Might be better to set up a network share and backup to that - that way with Samba you could backup both Linux and Windows on a native ext file system on a Linux box. HTH! Hi Tom, Works for me, thanks. I've given karma but it probably won't help much :-) I think this bug can be closed. -c ntfs-3g-2011.4.12-5.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report. ntfs-3g-2011.4.12-5.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report. ntfs-3g-2011.4.12-5.el6 has been pushed to the Fedora EPEL 6 stable repository. If problems still persist, please make note of it in this bug report. ntfs-3g-2011.4.12-5.el5 has been pushed to the Fedora EPEL 5 stable repository. If problems still persist, please make note of it in this bug report. ntfs-3g-2011.4.12-5.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report. |