something strange with ntfsbitmap
LINUX based utility for use with gnuddrescue to aid with data recovery
Brought to you by:
maximus57
Menu
▾
▴
While $bitmap in this case has only one extent, ddru_ntfsbitmap reads many pieces of it and result is completely wrong (it counts 150GB instead of 13, as far as I see -- most of it because of filling "unread" portions). An archive with boot, mft, bitmap, their offsets in bytes and ddru_ntfsfindbad log will be in "reply" topic.
Here it is (offsets are from drive start, not partition).
Edited to add a new FIRST possibility. Did you make sure that the directory that you are using was CLEAR OF ALL OLD FILES from any previous runs of ddru_ntfsbitmap? Any files left over from a previous run, or possibly a FAILED RUN DO TO WRONG OPTIONS can create unwanted results. More specifically, delete all files that end with ".log" to start over. That makes ddrescue think that the files have not been read yet and will redo them. Although it would be best to clear all files totally to be sure.
I have not had time to take a close look at all the files, but I did insert the $MFT file into a test, and it did read only one part of the bitmap file. I think maybe the __mftshort file is wrong in some way and needs to be re-read. If you still have issues after clearing all files and starting over then please let me know and I will look into it further.
^^^^^ SEE ABOVE PARAGRAPH FIRST ^^^^^
First and most important, do you know for sure this disk only had 13GB of used space before failing? Where are you getting that number from? This looks like a 500GB disk with a 484GB NTFS partition, and 13GB seems kind of small for something that probably had a windows installation on it.
Second, the bitmap file is damaged. Part0 rescued 3153kB but had an error size of 49152B and part1 had 10514kB rescued with an error size of 36864B. All non-trimed, non-split, and error areas are filled with 1's in the bitmap file because there is no way to tell if the space was used or not. So that space had to be considered used or something could be missed.
49152+3686484096= 2818572288 (errorsize(s)bitsperbyteclustersize= totalunknown). This does only adds up to just under 3GB of unknown. So I would think that the rest of the 155GB is actually known to be used.
I would question my math, except for the fact that the total_size = 500105740288. This number is aquired from doing a seek to the end, and it is close enough to the other total of 484272504832 to tell me that I am likely correct.
Last edit: maximus57 2014-04-18
I have finally had time to examine the MFT entry for the bitmap file, and you are correct that the bitmap file is not fragmented and should only be one part. Please see the above edit about clearing all ddru_ntfsbitmap files out and starting over. If that doesn't work then I would need a debug log from ddru_ntfsbitmap and all the other files it creates.
If clearing all the files works, then maybe I should make it do that by default and add an option to continue if needed.
I never heard back, did clearing the files fix the problem? I added a new option now to restart which will clear all the output files for a fresh start. If there is still an issue I need to know so I can address it.
Scott
Sorry for long silence, and yes, clearing previous logs helps, thank you! I have not tried yet version 2.4 but deleting previous files manually did fix the issue.