1

I lost my Desktop folder(I had a lot of stuff there.. maybe 1000 files). And used a tool to recover the deleted files right away. If found all the deleted files and recovered them. They all looked ok as far a dates and sizes, etc... So, I copied them back to my desktop folder, only to find out that every single one was 100% NUL inside. I don't think they even have any carriage returns. Just one long string of nulls. The files are the correct sizes though. So..

Luckily, I had an old backup from 1.5 months ago and was able to restore about 80% of the files.

But now I have 20% of the files, full of NULLs scattered throughout the desktop and folders on the desktop.

I don't know Python, and I cannot find any tool to identify these files. It seems crazy to me that there is no tool someone has made that can find a file that is full of 100% NUL 00 characters??? I'm 61 now and retired, but I was a software developer and I don't want to learn a language just to do this.. This does seem like an opportunity for someone to make a tool to share. I've tried grepWin using Regex searches, and searched all over but I have found many people trying to do the same thing and failing..

I have some sample NUL files to test with. I don't see any way to upload them here..

1
  • 1
    You can get a count of non-null bytes from tr -d '\0' < myFile | wc -c. Wrapping that inside a recursive find, and converting that output to a rm -f script, should do it. Except for genuinely empty files, though.
    – Paul_Pedant
    Jul 13, 2020 at 17:32

2 Answers 2

0

Thank you Paul. For some reason I cannot comment on your answer. It says that I "must have 50 reputation to comment". Maybe because my question was migrated from the Unix forums? IDK..

Is your reply a grep command? If so I also need some basic direction on this. I have searched and searched and have tried grepWin(which I can't get to find 100% null files), and downloaded grep3.4(but no commands work? Maybe it needs a System Path setup?, IDK), and found GnuWin(which I don't think is what I want, as it seems it is only for 32 bit systems, and I'm in Win 10 64)... I also searched for beginner tutorials, but none of them showed how to just setup Grep to work.. They all start showing you basic commands...

Again, thank you for responding. Hate to be a pain.. Any help is greatly appreciated as I've been trying to figure this out for about 5 days now.. and feeling pretty stupid at this point.

0
0

Sorry for delay -- I didn't get a notification from your answer because I commented as a guest.

This is a tested script that might need a little adaptation.

#! /bin/bash

    find 2>/dev/null . -type f -size +0c | while IFS= read -r fn; do
        NN="$( head --bytes=128 "${fn}" | tr -d '\0' | wc -c )"
        (( NN > 0 )) && continue

        NN="$( tr -d '\0' < "${fn}" | wc -c )"
        (( NN > 0 )) && continue

        printf "rm -f '%s'\n" "${fn}"
    done

As written, it creates a list of commands to remove all files in a directory tree which are entirely NUL characters. You could redirect that list into a file to check it, and then just bash < myRmFile. Or you could just put | bash directly after the done.

The outer loop find ...; do ... done searches the directory recursively from where you run it. The options to find select only regular files at least one byte in size, and then we read the names into the variable fn one at a time.

The next two lines are a pre-check optimiser, to save reading the whole of every file. It checks just the first 128 bytes, because any decent file will not have 128 NUL bytes and then something else later.

So we assign a count to NN from a pipeline of three commands. The head picks the first 128 bytes out, the tr deletes every NUL, and the wc -c counts what's left. If any non-NUL bytes are left, we continue with the next filename.

The next two lines do the same, but on the whole file, in case we hit a "non-decent" file.

Anything that failed both those checks generates an rm instruction for that file.

This is a bit flaky on some extreme filenames -- ones that contain single quotes or newlines in the name. And it runs an rm process per file, but you seem to only have about 200 so that's not critical.

Post again if you have problems.

You must log in to answer this question.