Doesn't appear to undelete PCM data. about xfs_undelete HOT 4 CLOSED

Huge files in principle aren't a problem as long as they don't have more extents as there are fitting in one inode record. It's 21 extents for 512 byte inode size. If your file has more extents, XFS uses a different format which is not recoverable by the method xfs_undelete uses.

Is your file a sparse file? That means, it has holes in it? Some tools create such files. Xfs_undelete by default ignores sparse files that do not have any extent starting at file position 0 — at the very start. Normally, such “files” found by xfs_undelete are bogus. But in your use case, it may be actually valid.

Comment out the test at line 215 of the script and see if that solves your problem.

from xfs_undelete.

Didn't seem to help. Tested with a smaller 'recently deleted' file.

Fortunately, just looking at the whole block device, about 8M at a time, about once every 50GB was good enough to catch a couple samples of the data I was after.

I did this with the file taken using a loop calling dd a bunch of time, accumulating onto the 'map' file, which I then opened with snd, which, being very well written is very good handling such data, so that even if it was obviously never designed to handle files vastly bigger than system ram, at sample rates in the MHz, it still works very well, so long as one is patient.

I opened the map, zoomed out, waited a few minutes for snd to look over the whole file and generate a min/max pixel map to look at, and then I went hunting for the signal behaviour I knew the right file would have, and was able to locate it that way.

Once located, a bit more fiddling with dd and snd got me to where I have the original data safe again. (albeit with an incursion from some other file somewhere in the middle, oh well).

Might not be an applicable technique for others, but practical as it was just such a large 'needle' to find in that haystack, and it wasn't very fragmented owing to that drive mostly being used to record such files.

I could only do this because I knew what shaped pulses to expect where in the data, from having looked at it in snd beforehand.

Once bitten twice shy: The datalogger script I use now runs as another user, so captured files look read only to me now (I also set the sticky bit on the directory).

Thanks for the assistance anyway, I'm still not sure why it didn't see these files.

from xfs_undelete.

I can't tell either. XFS has just too many options and versions and maybe there's a new inode format xfs_undelete isn't aware of yet. I wrote it along the documentation and tested it with the filesystems I have at hand or could create with my set of tools and it works.

I have to do more tests, it seems.

from xfs_undelete.

Unfortunately, I have been unable to find a solution to your problem. Sorry.

I'm closing this issue. Feel free to reopen if you have new information.

from xfs_undelete.