A while ago I backed up a Linux folder onto a Windows disk drive I had lying around. Recently I was scanning through those files when I realized that I had unintentionally copied over many unwanted hidden files and folders. I wanted to securely remove the files, but I realize that was not certain on a journaled file system (NTFS). So I figured the next best thing would be overwrite the files while keeping them intact, then overwrite the free space afterwards.

I cd into the folder that contained the Linux backup and tested: find . -regex '.+/\..*' which found all the files that I wanted removed. I then ran find . -regex '.+/\..*' -execdir shred -x -n 1 '{}' ';' and left my computer. When I came back a couple hours later, I tried changing directories but got I/O errors. I tried remounting but was confronted with even more errors. The partition on the drive is now missing.

I ran ntfsck and was given the following response...

Boot sector: Bad jump.
Boot sector: Bad NTFS magic.
Boot sector: Bytes per sector is not a multiple of 512.
sectors_per_cluster (161) is not a power of 2.
Failed to read file record at offset 5277682939987718400 (0x493e18abeb1b7100).
Loading $MFT runlist failed. Trying $MFTMirr.
Failed to read file record at offset 1872635234051646016 (0x19fcefd2df876240).
Loading $MFTMirr runlist failed too. Aborting.
NTFS signature is missing.

Have I unintentionally wiped my entire drive? If so, what did I do wrong?

  • What was your pwd when you issued the find ? – Citylight Dec 29 '14 at 5:02
  • /mnt/2013\ BU/linux/ – data_sunk Dec 29 '14 at 5:06
  • 1
    Did this directory happen to contain any dev nodes? – psusi Dec 29 '14 at 15:29
  • Probably you have had things like .udev/sda device files which you shredded. – Stéphane Chazelas Dec 29 '14 at 16:05
  • People responding to this question please remember he's mounted an NTFS partition, and is deleting files under NTFS. NTFS doesn't treat devices as files. – Steve Sether Dec 29 '14 at 18:48

Your find command is fine, and so are the options to the shred command. What I suspect happened is that shred is doing something that NTFS and the linux NTFS module don't like. Shred attempts to write and re-write many many times and do other "out of the ordinary" things to make sure data is over-written, and perhaps the linux NTFS driver isn't built for that?

The fact that you're getting errors when you try to mount the filesystem indicate something went wrong at the filesystem level. The options you put into shred should only delete files, not write directly to a device, so I don't understand how else you could have damaged the filesystem other than a broken driver.

I'd suggest mounting the NTFS partition under windows, and see if it can repair whatever damage was done.

| improve this answer | |
  • That's possible, though if even the partition table is affected, it would be a pretty grave driver bug (writing outside the partition). – Gilles 'SO- stop being evil' Dec 29 '14 at 22:23
  • Well, it doesn't have to write outside the partition, just corrupt the NTFS filesystem in some way to generate the NTFS mount errors. Though he did mention the partition was "missing", which is weird. I'm not familiar enough with NTFS to interpret the error messages other than "Something is corrupted", which I can't explain unless you assume driver bugs. – Steve Sether Dec 29 '14 at 22:49

Working directory doesn't matter. That regex matches all hidden files and directories systemwide.

+. one or more characters

/\.followed by /.

.* followed by zero or more characters.

Try it in here and put some paths in and you will see what happened http://regexpal.com/

I hope you had a backup because your system is dead. You need to reinstall.

Edit: Fixed the wrongness there, could it be the -x flag on shred leaving the block sizes wonky and NFTS having a hissy fit about it?

| improve this answer | |
  • While the analysis seems correct, the conclusion isn't. This find call located all hidden files and directories (and their files, hidden or not), and should have shreded them. Besides, the OP states than the find call did locate the correct files. – John WH Smith Dec 29 '14 at 10:55
  • The command is run in a specific directory ( that is not the root ) and so only will find files in that directory or subdirectories, not all files on the entire system ( which would also have meant that ntfsck would be gone ). – psusi Dec 29 '14 at 15:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.