|
From: Krist P. <kr...@gm...> - 2009-10-03 07:13:42
|
hi Anton, Thank you for your quick reply. You're right about the data not being recoverable, and it's most likely all fragmented as i could see from the data runs in the large files i did recover, there were pieces all over the place. So scanning the disk is just not possible. What i wanted you mention however, is that while *all* my files smaller than 4 Gb have been 100% recovered, *none* of my files larger than than 4 Gb were recoverable; their length is claimed to be 0 and all data runs empty. I had about 20 files like this. So i reckon there is something "special" about > 4 Gb files. As a programmer i know this has long been a boundary, and it's MAXINT, so lots of capacity issues and limitations. It could be either something funny / different in NTFS with > 4 Gb, or perhaps a MAXINT issue in "ntfsundelete"... who knows... Anyway I am most impressed with your program and it has saved my files. cheers and thank you for your work ! best wishes, krist. Anton Altaparmakov wrote: > Hi, > > On 1 Oct 2009, at 08:13, Krist Paquay wrote: >> hi guys, >> >> First of all let me thank you for this fantastic program ! >> >> I accidentally removed my ghost image files (silly me) but thanks to >> your "ntfsundelete" program i have most of it back, GREAT. >> >> I did notice however that files larger than 4 Gb are not recoverable, >> pity. All off my other files have been recovered fine. >> >> The output from "ntfsundelete -v" on a big (> 4 Gb) file is: >> >> File has an empty runlist, hence no data. > > That means there is no runlist which means we do not know here the > file was on disk so we cannot recover it at all. There is nothing we > can "fix" to recover this file it simply isn't there any more or > rather the information telling us where the file was is no longer > there which is why we cannot recover it any more... If you knew the > content you could probably scan the disk and find the actual data on > it and put its pieces back together but that would be a lot of hard > work and for such large files there is unlikely to be any hope of > success... The file was probably fragmented so as part of the > deletion Windows probably removed the attribute list attribute which > caused it to rewrite the data attribute (which contains the encoded > runlist) and only then did it delete the file which means it is gone > for good. > > Sorry not to be able to offer you better news. > > Best regards, > > Anton > >> File is 0% recoverable >> MFT Record 60359 >> Type: File >> Date: 2009-09-26 11:19 >> Filename: (2) 2009_0~2.TIB >> File Flags: <none> >> Size alloc: 9235496960 >> Size data: 9235495424 >> Date C: 2009-09-26 11:01 >> Date A: 2009-09-26 11:19 >> Date M: 2009-09-26 11:19 >> Date R: 2009-09-26 11:19 >> Filename: (1) 2009_09_26_temp.tib >> File Flags: <none> >> Size alloc: 9235496960 >> Size data: 9235495424 >> Date C: 2009-09-26 11:01 >> Date A: 2009-09-26 11:19 >> Date M: 2009-09-26 11:19 >> Date R: 2009-09-26 11:19 >> Data Streams: >> Name: <unnamed> >> Flags: None >> Size alloc: 0 >> Size data: 0 >> Size init: 0 >> Size vcn: 0 >> Data runs: >> None >> Amount potentially recoverable 0% >> ________________________________________ >> >> Just though you might like to know this. >> BTW if you have a fix or so i'll be glad to check it out. >> >> Many greetings, >> >> krist. |
