Page 1 of 1
o bytes file
Posted: July 28th, 2014, 4:43
by DRCP
Hello,
Major JPG files in folders showing 0 bytes .
Root folders size is 64 GB (as user says) but now showing only 4 gb.
Many jpg files showing 0 bytes file size. i tried raw recovery also but raw recovery also showing 4 gb data.
Any suggestions
Thanks in advance
Re: o bytes file
Posted: July 28th, 2014, 7:29
by HaQue
If RAW recovery does pull out files, and the files are 0 bytes, I think game over.
Have you taken an image of the drive and looked at it in a HEX editor? Is there anything that looks like a complete jpeg header in there?
What happened to cause this? RAW recovery performed with what?
filesystem FAT/NTFS/other? I am not liking the sounds of it though

Re: o bytes file
Posted: July 28th, 2014, 11:39
by DRCP
No raw recovery does not show files.If i check directly in specific folder its showing me files of 0 Bytes.
if i tried copy through DE its saying Saving process complete but that file does not appears in destination folder.
if opned directly says Error FillDirNew() -> Can't create map! Runs Count is not found or is equal to 0!
if i open this file in winhex shows empty(1.Jpg)
Cause : user saying while copying file i observed this issue.
File System NTFS
Re: o bytes file
Posted: July 28th, 2014, 16:46
by fzabkar
Locate the starting cluster/sector for DSC05918.JPG and then examine that sector in your hex editor.
Re: o bytes file
Posted: July 28th, 2014, 17:19
by DRCP
this is first sector
Re: o bytes file
Posted: July 28th, 2014, 20:40
by HaQue
maybe malware?
Re: o bytes file
Posted: July 29th, 2014, 17:48
by fzabkar
The way I would approach this problem would be to locate the file's INDX and MFT records, and then examine their structure. For example, there are separate fields for the file's real size and the space it actually occupies.
A 1-byte file would occupy one cluster, which is typically 4096 bytes. However, I don't know what to expect for a genuine 0-byte file under NTFS. Under FAT32 such files are not assigned to any cluster, so the actual occupied space is 0 bytes.
I would start by comparing a real 0-byte file against the suspect ones. To this end you could create such a file using the following command at the CMD prompt:
rem > zerobyte.bin