0

A directory on an NTFS partition no longer lists its contents, but the files are still there if I can remember their full names. Is there a way to get the directory listing working again?

I caused the breakage by (stupidly) yanked an external disk's lead out before the computer had reported that it had been unmounted successfully. The partition is NTFS, mounted on Ubuntu Linux as type fuseblk. I'd just copied a file into a directory on it. The copy command had finished. I then ran umount on the mount point, waited a few seconds for it actually to unmount, and then took its lead out (before then realizing that I hadn't actually seen umount successfully complete).

On re-mounting, the rest of the disk contents seems fine, but the directory I was copying the file into won't display its contents. If I cd to that directory, I get this:

$ ls
ls: reading directory 'purple': Input/output error

However, from that same directory, if I can remember the name of a subdirectory, the files in there are listed, and open just fine:

$ ls London
[contents of the London subdirectory displayed]

I don't think I've actually lost any files — at least for any subdirectory names that I can remember the names and exact spelling/punctuation/capitalization of.

Is there any way to recover the directory listing, or find out which subdirectories are in it? Clearly the information is still on the disk somewhere. Even recreating a directory listing with bogus names (dir0001, dir0002, etc) would be fine: I could look inside them to manually rename them back.

Smylers
  • 155
  • 6
  • I'm assuming you've done the obvious first step: `fsck` the drive? You can plug it into a Windows machine and do a `chkdsk /r` if you want the official NTFS standard. – tsc_chazz Nov 07 '22 at 19:51
  • Thanks. No; I didn't want to risk doing anything that might write to the risk and then being told that had destroyed any chance of something else working — so I asked here first. I wasn't even sure `fsck` was the right tool for NTFS. – Smylers Nov 07 '22 at 19:54
  • 1
    `fsck` is actually a front end which checks for the drive type, then invokes a program specific to the filesystem type, if I recall correctly. It should do what you need to do, but there is a risk. The safest course is the Windows `chkdsk` which normally does not delete orphaned files but saves them for you, albeit often without the original names or types. – tsc_chazz Nov 07 '22 at 20:01
  • Thanks. I shall try to find a Windows computer and give that a go. – Smylers Nov 07 '22 at 20:34
  • I found somebody with a Windows 10 computer, plugged it in ... and it just displayed the ‘missing’ directory just fine, with all its contents. I created a file in it, wondering if that will re-write the directory listing and then work again on Linux. Unfortunately neither I nor the Windows user could find an unmount/eject/safely remove option, so I now have to wait till they've finished with their computer and are shutting it down anyway. – Smylers Nov 09 '22 at 13:25
  • I've got a few external drive carriers with that problem, a proper PITA that is, thank you Microsoft. If the directory listing is OK on Windows, then almost certainly an fsck will bring the directory back if it isn't there now... but you might want to create a second directory on the Windows machine and copy your files there for safety. If you want to check the disk while it's plugged in, that's right-click on the disk, Properties, Tools, Error-checking. – tsc_chazz Nov 09 '22 at 17:15

0 Answers0