Jump to content

Welcome to MSFN Forum
Register now to gain access to all of our features. Once registered and logged in, you will be able to create topics, post replies to existing threads, give reputation to your fellow members, get your own private messenger, post status updates, manage your profile and so much more. This message will be removed once you have signed in.
Login to Account Create an Account



Photo

lost partition and filesystem problem with Adata SH14 disk

- - - - -

  • Please log in to reply
34 replies to this topic

#1
nthnl

nthnl

    Newbie

  • Member
  • 17 posts
  • Joined 11-November 13
  • OS:Windows 7 x64
  • Country: Country Flag

Good day chaps,

 

The situation:

I an having trouble wtih a company owned ADATA SH14 (1Tb space). We gave the disk to another company to write data to it, but when they gave it back to us the drive was showing as RAW. They lost the USB3 cable and tried to use a Micro USB cable instead and claimed that the drive was functioning properly on some of their computers. As of this moment I have extracted most of the data from the drive using iCare Recovery Software but unfortunately the names of some of the files and the directory structure is gone which makes most of the data unuseable. I read of lot of forum threads but I was not able to find one that describes my problem.

 

I tried to use TestDisk to repair the drive and here is what happend:

1. The first analizing tool does not find a partition at all.

2. The deep search finds a partition but when i try to browse the files it says that the filesystem might be corrupted and does not show even 1 file.

3. On the next menu it says:

Boot sector:

fat32_boot_sector: Can't read boot sector

Bad

 

Backup boot sector
Ok

 

4. I tried to use the "Backup BS" but it reports that it can not overwrite the FAT23 boot sector.

5. I tried the "Rebuild BS" and after waiting for nearly a day it found a directory with some files but when prompted to write the data it failed with the exact same error.

 

Drive shows as:

FAT32 LBA 0    1   1   121600    254      63 1953520002

 

I would really appreciate any suggestions you can give me! :)

 

Kind Regards,

Mihail Velikov

System Administrator




How to remove advertisement from MSFN

#2
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,579 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag

But was the drive actually originally formatted as FAT32 (it would be extremely rare that a 1 Tb drive is formatted with the FAT32 filesystem in a single partition :ph34r:)?

There is no problem in rebuilding a FAT32 bootsector :), but the issues here are (IF the drive was actually FAT32) the FAT tables.
VERY loosely speaking, any file which is:

  1. NOT fragmented
  2. NOT residing in the root directory

should be recoverable alright from a FAT32 filesystem. (IF the issues are limited to the FAT tables)

Are you working/modifying the original :w00t: or using an image (or anyway have already an image safely stowed away)?

Which OS are you running/using to attempt accessing it?
 

Have you considered that the issue may be - even partially - connected with the actual USB to SATA controller inside the disk case?

 

Do you have the possibility to open the case and connect directly the disk to a SATA bus?

 

jaclaz



#3
nthnl

nthnl

    Newbie

  • Member
  • 17 posts
  • Joined 11-November 13
  • OS:Windows 7 x64
  • Country: Country Flag

Hello Jacklaz,

 

I really do not believe that the disk was FAT formatted. Unfortunately as I am not the one that initialized the disk so I can't be 100% sure.

 

I am currently working the original and not using an image. I have already extracted the data and this is last ditch attempt to save the drive. The other step will be reformatting it.

 

Initially I was using Windows 7 with the iCare software to recover the files. Currently the disk is attached to another systems running partedmagic boot cd.

Regarding the SATA controller - no I haven't thought about that. The disk is sealed in a rubber thingie but i could still try to open it. I will try this right now.

 

Update: Ok, i opened the case and extracted the disk. I have now connected it to the computer and I will see how it is going to behave. Should I run testdisk again to analyze the drive?

 

Kind Regards,

Mihail Velikov
System Administrator


Edited by nthnl, 11 November 2013 - 07:00 AM.


#4
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,579 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag

In this particular case I would run on it - instead of TESTDISK - the DMDE.

(Testdisk is mainly intended for "corrupted partition" recovery and has only some very limited features when it comes to filesystem recovery).

Still, if you run again TESTDISK with the LOG option and post the log, it may contain something of use to give you some further advice.

DMDE is a very nice (IMHO) tool that has a Free Edition with not-so-limited features, that I often use to inspect damaged filesystems:

http://dmde.com/

 

In any case the "correct" procedure would be to first thing do a "forensic sound" image of the disk "as is".

 

No offence whatever intended :), but while "pure file-based recovery" (such as PhotoRec or similar) offers no risks to the integrity of the filesystem, running TESTDISK or similar software and attempting to WRITE :ph34r: to the target may make things worse that they were before.

 

I am not familiar with the software you mentioned, actually never heard of it before :w00t:, so, even if it is an exceptional good tool :unsure:, I would anyway go for a second (or third) opinion both as "filesystem based" recovery and as "pure file-based recovery" through the use of other tools.

 

jaclaz



#5
nthnl

nthnl

    Newbie

  • Member
  • 17 posts
  • Joined 11-November 13
  • OS:Windows 7 x64
  • Country: Country Flag

Hello Jacklaz,

 

Thank you very much for your advice.

I do not believe that the software I used made any changes to the disk - although I might be wrong. About TestDisk - yes, I tried to write to the disk but it failed so I am not sure if it actually wrote anything to start with.

 

I will try the DMDE tool and see how it goes. If I can make a better backup of the drive it would be great.

Update: I am running DMDE and it gives a log of errors looking like that (only the Sectors are different, also note that the drive is directly connected to the sata port on the motherboard):

LUN#0 Sector 63(try 2): WinError 23. Data error (cyclic redundancy check).

Update 2: DMDE reports this is a FAT32 File System and is currently testing FAT tables - still gives a lot of error like the one above.

 

Kind Regards,

Mihail Velikov

System Administrator


Edited by nthnl, 11 November 2013 - 08:19 AM.


#6
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,579 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag

Those kind of errors are not "good news" :(.

They appear to be "low-level" errors :ph34r: (i.e. either the disk controller or the SATA cable or - more probably - the disk itself have hardware issues).

(BTW they could be also originated by the Windows 7 OS, but it would be "queer")

 

Now, much more than before, it is imperative that you:

  1. stop fiddling with that disk drive. like NOW (sometimes a defective disk only needs to cool down a bit)
  2. procure yourself another disk slightly bigger with a partition/volume formatted as either NTFS or Ext2/3/4 to make on it an image of the disk
  3. get *any* Linux distro with Gnu ddrescue and use it to make the image

https://help.ubuntu....system_or_drive

 

BTW, there is a similar software for Windows:

http://www.datarescu...cue/v3/drdd.htm

but the GNU ddrescue offers some added functionalities (it will skip defective sectors, logging what was skipped and you can re-run it and will automatically try to re-read the skipped ones), you can do more or less the same with datarescuedd, but you need to image in chunks (manually) and re-assemble chunks, see:

http://reboot.pro/to...-clicking-disk/

http://reboot.pro/to...-disk/?p=133567

 

The first error being on sector #63 makes a lot of sense as - IF the disk was originally partitioned using the old CHS convention -  sector LBA 63 is actually the bootsector of the partition (i.e. the thing that TESTDISK had issues writing to).

 

jaclaz



#7
nthnl

nthnl

    Newbie

  • Member
  • 17 posts
  • Joined 11-November 13
  • OS:Windows 7 x64
  • Country: Country Flag

Hello Jacklaz,

 

Ok, I will order another drive, because I don't have one that big on my disposal right now.

 

The check of the FAT tables just completed and here are the results:

FAT table size in bytes: 122065408

 

radio box 1: FAT1: 4096-122065408: 100% OK; 30%OK, 0 % bad, 69% empty, 0% unknown

radio box2: FAT2: 4096-122064896: 99% OK; 29% OK, 0% bad, 70% empty, 0% unknown

radio box3: do not use FAT tables

 

check box: check (do not use bad sectors)

 

Any idea which one should I choose or should I just end task the application then make the image of the drive?

 

Kind Regards,

Mihail Velikov

System Administrator



#8
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,579 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag
These results are not that bad:

The check of the FAT tables just completed and here are the results:

FAT table size in bytes: 122065408
 
radio box 1: FAT1: 4096-122065408: 100% OK; 30%OK, 0 % bad, 69% empty, 0% unknown
radio box2: FAT2: 4096-122064896: 99% OK; 29% OK, 0% bad, 70% empty, 0% unknown
radio box3: do not use FAT tables

BUT they are not "normal".
I mean it seems like the two copies of the FAT are overlapping.

Any idea which one should I choose or should I just end task the application then make the image of the drive?

If you choose the "do not use FAT tables" the filesystem will be read as "RAW" and as such only files that are contiguous and in any subdirectory may be recovered (BUT, IF the FAT tables - even if "OK" - do contain invalid or incomplete data, this option may allow to recover MORE files than when using the supposedly "100% OK FAT table", on the other hand, it is well possible that the second FAT table, though not "100% OK" may contain "different" - possibly "more valid" data.
The "standard" procedure when you know WHAT you are actually looking for is to try checking the files/directory tree once for each option and then choose the one that shows the needed file(s).
If you don't know what you are looking for, the procedure is to run the whole recovery process three times, and then compare results.
The real issue here is that - depending on the reason that caused the sector level errors - it is possible that each read operation/movement of the head on that disk makes things worse, and - besides - working on an even partially defective disk will slow down operations to a level that is almost unbearable.
That's another reason for making the image, it may take a lot of time to create (hopefully) a valid image, but the imaging tool can be run "unattended" at night, and once you have the image on a "good" disk, the interactive part of the recovery (analyzing/searching/copying/etc.) will be faster.


I would no doubt have the image made next thing. (better be safe than sorry ;))

Can you post the EXACT model of the actual disk drive?
I want to check it's actual sector size and number of sectors as something - instinctively, but I have do make some calculations - doesn't "sound" right to me about the FAT size found.

jaclaz

#9
nthnl

nthnl

    Newbie

  • Member
  • 17 posts
  • Joined 11-November 13
  • OS:Windows 7 x64
  • Country: Country Flag

Hello Jacklaz,

 

Indeed you are correct - > better safe than sorry. Reading the disk is extremely slow so I will do an image when the new drive arrives and see if I can extract any useful data from it.

Regarding the actual drive it is:

Samsung

Model: HN-M101MBB   (1Tb/5400rpm/8M)

LBA 1,953525,168 1TB

REV. A

S/N: S2R8J9BB901504

P/N: C7612-G14A-A47PT

 

As soon as I have any news I will update the thread.

 

Kind Regards,

Mihail Velikov

System Administrator



#10
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,579 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag
Good. :)
The disk is seemingly one of those with the "newish" 4096 bytes per sector "advanced" format:
http://www.storagere...point_m8_review
but as a mattter of fact it seems like it "exposes itself" as a conventional 512 byte/sector device.
As such the offset of 4096 bytes for the start of the FAT1 seems like "possible or probable".

Quite surely the good guys at ADATA have created the FAT32 filesystem with a "cusstom" app (the "standard" Windows format won't deal with such a large disk or will create a "huge" cluster size, but in any case it would create a higher number of "reserved sectors").
I didn't think it was a 2.5" drive, and yes, I have seen how those are often formatted as FAT32 even if very large, in factory, so that the "common" user can use them on Windows, OSX and Linux "as is".

As well, the size of the found FAT seems like "right", 122065408/4=30516352 (roughly) indexable clusters, and if you divide 1953520002 (total sectors - these are 512 bytes ones) by 30516352 you get roughly 64 which makes sense for a 32 Kb cluster FAT filesystem.

It is possible (but I doubt it) that the "custom" format had only one FAT table, but in any case the FAT1 that the tool found - according to the data posted - sounds like "the right one". :thumbup:

jaclaz

#11
nthnl

nthnl

    Newbie

  • Member
  • 17 posts
  • Joined 11-November 13
  • OS:Windows 7 x64
  • Country: Country Flag

Hello Jacklaz,

 

I run the ddrescue on my disk and here is the output.

 

root@partedmagic:/dev# ddrescue -r 3 -n -v --force /dev/sdb /dev/sda recovery.log


GNU ddrescue 1.17
About to copy 1000 GBytes from /dev/sdb to /dev/sda
    Starting positions: infile = 0 B,  outfile = 0 B
    Copy block size: 128 sectors       Initial skip size: 128 sectors
Sector size: 512 Bytes

Press Ctrl-C to interrupt
rescued:     1000 GB,  errsize:   1372 kB,  current rate:        0 B/s
   ipos:   180815 MB,   errors:      21,    average rate:   31125 kB/s
   opos:   180815 MB,    time since last successful read:      20 m
Finished

 

I will now try to see if the data is structured better than before from the healthy drive.

 

Kind Regards,

Mihail Velikov

System Administrator



#12
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,579 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag

I will now try to see if the data is structured better than before from the healthy drive.

Yep.

If the DMDE found FAT table has not errors, as it seemed, now that you have the data on a surely working device, you can try also re-running TESTDISK, if it now can write to the bootsector, most probably it can fix the filesystem enough to acess the data "normally".

But can you post the actual recovery log?

BY checking the location of the chunks that errored out it is possible to see if they beloong to filesystem data or to the actual data, as this makes a big difference (between being unable to access some 16,000 entries or being unable to access - or get corrupted - 1 or two files)

In any case usually the idea is to re-run the tool a couple more times with the "-C" option to see if it can recover the "errored" areas, possibly by using a smaller block size:

 

`-c sectors'
`--cluster-size=sectors'
Number of sectors to copy at a time. Defaults to 64 KiB / sector_size. Try smaller values for slow drives. The number of sectors per track (18 or 9) is a good value for floppies.

 

and/or using the "reverse" approach:

 

`-R'
`--reverse'
Reverse direction of copying, retrying, and the sequential part of splitting, running them backwards from the end of the input file.

 

 

 

jaclaz


Edited by jaclaz, 13 November 2013 - 05:00 AM.


#13
nthnl

nthnl

    Newbie

  • Member
  • 17 posts
  • Joined 11-November 13
  • OS:Windows 7 x64
  • Country: Country Flag

Hello Jacklaz,

 

I run the DMDE tool on the new drive aaaaand gues what -> again I see the errors that the previous disk gave me. I do not belive this is a disk issue as it is brand new. I am currently doing a full scan on the hard drive with DMDE for file and director fragmest and it is currently on 85% (started it around 8 hours ago).

 

Regarding the recovery.log - unfortunately I didn't save it. I was runing the parted magic boot cd which operates in the RAM and I didn't attach a working disk to copy it to (my bad ..).

 

I will see how the DMDE will do - before doing the full check it was actually giving me nearly the same folder structure as the software I initially used to recover files. If it still fails I will go ahead and run testdisk and try to repair the drive.

 

All in all I am quite happy to learn a lot of new things about HDD recovery - god know when I will need it again :)

 

Kind Regars,

Mihail Velikov



#14
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,579 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag

Anyway, should you not be able to recover the data this way, we can still try assuming that your previous DMDE scan for FAT was accurate and recreate a new bootsector with the  relevant BPB data on it.

 

You can also use DMDE (or any disk editor) to look manually in the disk to check for the FAT start.

Typically it is a few sectors after the bootsector (8 according to your previous DMDE scan) and basically it is the first sector that starts with the F8 FF FF 0F FF FF sequence.

The previous scan of DMDE says that the FAT size is 122065408, the "sectors before" from your initial posts are 63 and the partition size is (still from there) 1953520002 sectors.

The only thing that is not clear or "queer" is the number of FAT's, from the DMDE scan you reported it may be that there is only one table (and DMDE assumes that a part of the FAT1 is actually the FAT2) but this is "uncommon" as normally there are two copies of the FAT table.

 

If you want, you can dd the first 100 sectors of the disk, compress them in a .zip file and either attach them to your post or upload to any file hosting service and post the link.

From Linux, that would be:

dd if=/dev/sdb of=100sects.bin bs=512 count=100

(of course the command must be run from RW mounted filesystem or anyway the of= file must be on such a filesystem, i.e. include a path to it)

 

It would be easy if the data is confirmed to prepare a couple bootsectors, one with just one FAT and the other with two FATs.

 

jaclaz



#15
nthnl

nthnl

    Newbie

  • Member
  • 17 posts
  • Joined 11-November 13
  • OS:Windows 7 x64
  • Country: Country Flag

Hello Jacklaz,

 

I left the drive last night to complete the full indexing of the directories but unfortunately the computer applied updates and rebooted. FML right? I am not really in the mood to wait for it for a whole another day so I used the FAT1 and FAT2 tables that it got but unforutnately it found only around 950 Mb of useful data. I guess the full indexing will be required anyway.

 

Anyway I will run the full indexing process again and I hope it will complete properly this time. After it finishes I will extract the bootsectors and upload it here.

 

Kind Regards,

Mihail Velikov

System Administrator



#16
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,579 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag

Hello Jacklaz,

 

I left the drive last night to complete the full indexing of the directories but unfortunately the computer applied updates and rebooted. FML right? I am not really in the mood to wait for it for a whole another day so I used the FAT1 and FAT2 tables that it got but unforutnately it found only around 950 Mb of useful data. I guess the full indexing will be required anyway.

 

Anyway I will run the full indexing process again and I hope it will complete properly this time. After it finishes I will extract the bootsectors and upload it here.

 

Kind Regards,

Mihail Velikov

System Administrator

Well, JFYI a non-written :w00t: Rule of data recovery is that when you set a machine to do something like that (imaging, scanning, etc.), you disconnect it form the internet/local lan (and possibly also disable any service not really-really needed).

 

I am sorry for your misadventure :(, but that is the essence of Murphy's Law, of which you provided an excellent example :ph34r:.

 

jaclaz



#17
nthnl

nthnl

    Newbie

  • Member
  • 17 posts
  • Joined 11-November 13
  • OS:Windows 7 x64
  • Country: Country Flag

Hello Jacklaz,

 

I have attached the file that you requested. In the mean time I will try and repair the disk with TestDisk and see how it goes.

 

Note1: I used the DMDE tool to index the files and directories and it found a lot of usefull files (the programs know about cyrilic symbols). The problem is that I have like 150 Gb of text files and I can't really save them 1 by 1. The bigger problem I think is that I did not find a way to save the index of the disk, so even if I want to buy the software I will still need to wait for it for whole another day to do the indexing again.

 

Note2: I run the TestDisk and it reported that both my primary and backup boot sectors are bad and only had the option to Rebuid BS. I quit the menu and went back to do a deeper search.

 

Kind Regards,

Mihail Velikov
System Administrator

Attached Files


Edited by nthnl, 15 November 2013 - 04:33 AM.


#18
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,579 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag

The good news are that the data you posted is not that bad. :)

At first sight it seems like there are remainders of the FAT table (at a more "normal" sector 95 - i.e. 63+32).

More exactly it seems like sector 96 is actually the 2nd sector of the FAT table (and 97 the 3rd, etc.)

The exceptionally good news are that from what I can see the first entry in the FAT was (hopefully) a single file, contiguous, around 13 Mb in size.

 

It is possible that there is a "way out" rebuilding the first sector of the FAT.

 

I need to understand however if there was just 1 FAT (which is improbable) or 2 (which would be "normal"), and have to check a few values/make a few calculations/experiments.

Give me some time and I may come out with a possible solution.

 

jaclaz



#19
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,579 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag
OK, the whole thing seems to make sense.
I am attaching a file 100 sector in size with a rebuilt bootsector (not bootable, just the BPB) and a rebuilt first sector of the FAT.
You should apply it to the image and then run again TESTDISK on the image.
Please run TESTDISK with the LOG option, so that if needed you can post the log I can possibly understand what is happening.
The file is made in the hypothesis that 2 copies of the FAT were there AND that I assumed/calculated the correct number of FAT dedicated sectors :ph34r:
 
But you could verify if the assumption is correct, before even doing the test.
You do have a disk editor/viewer, and know how to use it? :unsure:
(DMDE would do as well, but it is not very "friendly" as "pure" hex editor/viewer)
 
If you check the image sector 96, you will see how it starts with:
 
81 00 00 00 82 00 00 00 83 00 00 00 84 00 00 00 
and sector 97 starts with:
01 01 00 00 02 01 00 00 03 01 00 00 04 01 00 00 
etc.
The data in the bootsector I re-built uses:
63 "sectors before" <- these come from the MBR and are surely correct
32 "reserved" sectors <- these are more or less a "standard"
238409 sectors per FAT <- these are "calculated" and they may be incorrect

In theory, you should have on sector 96+238409=238505 the same data as sector 96, on sector 97+238409=238506 the same data as sector 97, etc.
It is possible that this won't happen, if the 238409 is wrong or if the second copy of the FAT has "larger" damages than first copy.
You could try going a few tens sectors back or forward and visually check if you see a similar pattern.
A contiguous file larger than a cluster is represented in a FAT32 table as a set of numbers (4 byte values) that are each the one before +1.

I hope I was clear.

jaclaz

Attached Files



#20
nthnl

nthnl

    Newbie

  • Member
  • 17 posts
  • Joined 11-November 13
  • OS:Windows 7 x64
  • Country: Country Flag

Hello Jacklaz,

 

Yes I know how to use a Hex tool. I downloaded one and I am currently viewing the disk.

 

So basically here is what I found:

1. From Sector 238504 to sector 238895 - completely empty.

2. Sector 238503 is like 60% written.

3. I went from Sector 238400 till 238505 no match for the 96 or 97 sectors.

 

So basically between sector 238400 to sector 238895 there are no copies of the 96/97 sectors

 

Could you please explain how are the sectores per FAT calculated?

 

Kind Regards,

Mihail Velikov

System Administrator



#21
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,579 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag

Basically.
A FAT32 table is nothing but a "sequence of groups of 4 bytes, each pointing to the next group in a chain, and each representing a cluster".
Each sector of 512 bytes contains thus 128 of such "groups"
A valid bootsector contains (related strictly to the filesystem) 6 pieces of info:

  1. how many sectors are before the beginning of the volume <-this is the same info that you can get from the MBR, i.e. 63
  2. how many sectors are reserved <- this are the very beginning of the volume and correspond to the bootsector itself, plus "auxiliary sectors", like the backup of the bootsector, code (in the case of a bootable volume) exceeding the bootsector, etc.
  3. the cluster size <- number of sectors that are indexed "together" i.e. 64
  4. how many FAT tables there are <- normally 2, in some rare cases 1
  5. how many sectors are "dedicated" to the FAT table <-these need to be "enough" to index the whole amount of clusters in the volume
  6. how many sectors are in the whole volume <- i.e. "size of the volume", this is the same info that you can get from the MBR, i.e. 1953520002

#1 and #6 are not a problem (as we got them from the MBR)

#2 is a guess, but a - allow me - very educated one, as when a volume is "large enough", 32 reserved sectors are common AND we found what has the aspect of a second sector of a FAT on sector 96. 

#3 is also a guess, but also a very educated one

#4 is one of the problems, as a "normal" Windows Format won't allow to create a FAT32 volume larger than a relatively small size and while almost all third party programs also use 2 FATs, it is possible that a "custom" programs creates just one

#5 is the biggest problem

 

You have a volume that has a sector size of 1953520002, of these 32 are reserved, so you have left 1953519970 sectors.

Of these we know that a (second) part is addressed in clusters of 64 sectors, and that before them there are a number of sectors, each addressing 128 clusters, times 2, and that these sectors must be enough to address each of the clusters in the second part.

So you have an equation *like*:

2x+y=1953519970

Where y should be in theory a multiple of 64 and x=y/128

The problem is with the "rounding".

I resolved (actually simulated your disk using a tool I have) the equation as:

2*238409+1953043152=1953519970

the 238409 sectors are enough to index 238409*128=30516352 clusters and 30516352*64=1953046528 (more than the 1953043152 remaining), BUT 1953043152 is not exactly divisible by 64.

On the other hand, with 238048 sectors I would have not enough "space" i.e.:

2*238408+1953043154=1953519970 238408*128*64=1953038336 (LESS than the remaining 1953043154 sectors).

BUT there is no actual "law" ;) preventing me from allocating a slightly larger amount of sectors for the FATs, and use not *all* of them.

In other words, I could decide to solve the equation as:

2*238417+ 1953043136=1953519970

and in this case I would have 1953043136 that is perfectly divisible by 64 (and I would simply have a few sectors of the FAT tables that will be never used)

Different formatting programs may use one or the other "strategy" or use a different "rounding" algorithm.

 

I hope that the above is clear enough, it's a bit complex, and it is not easy to "compact" this kind of info in a forum post. 

 

Please try posting:

  1. the sector 238503
  2. some 100 sectors starting from 238895 (or from the first sector after 238895 which is NOT empty)
  3. some 100 sectors starting from 238895-238409=486 (or from the first sector after 238895 which is NOT empty - 238409)

Maybe I can detect the "increasing number" pattern I was early referring to and be sure about the "sync" of the 2 tables.

I am still believing that there were originally 2 FAT tables, it is possible that just like the area from the bootsector to the first sector of the first FAT was wiped (or defective) a number of sectors from the second table were also in the same condition.

If there was only 1 FAT, the sectors that you scanned and found 00's, around 238505 and up to  238895 would belong to the first file or directory on the volume, 

There is another possibility, which is that is possible that the cluster size was, instead of 64 sectors, 128 (and thus the FAT size would be halved) but it would be "non-standard", compare with:

http://support.micro...kb/140365/en-us

 

 

jaclaz

 

 



#22
nthnl

nthnl

    Newbie

  • Member
  • 17 posts
  • Joined 11-November 13
  • OS:Windows 7 x64
  • Country: Country Flag

Hello Jacklaz,

 

First - thank you very much for the detailed explanation - as of now I have read it twice and it still doesn't make full sense but I will get the hang of it.

 

Second - I have attached the information that you required.

 

Thank you very much for your help and please excuse me for taking so much of your valuable time.

 

Kind Regards,

Mihail Velikov

System Administrator

Attached Files


Edited by nthnl, 18 November 2013 - 04:02 AM.


#23
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,579 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag

Well, it is really "queer".

 

If you search on your image with an Hex editor for the hex string B9 F5 00 00 BA F5 00 00, you should find it in two places (do NOT search for them from the beginning of the image, start searching from around sector 500 and from, around sector 238900:

  • on sector 586
  • on sector 238995

(this is where I have them in my "simulated" image, you will have to confirm this on the actual image you have or correct to the exact sector numbers where the strings are found)

As you can see, 238995-586=238409 (i.e. the size of the FAT table I have)

 

In both cases the string is at half of the sector, BUT it is at the beginning of the file you attached "sectors from 238896 to 238995" :w00t:

 

It seems like when you made that file you *somehow* introduced a "shift" . 

 

As I have hinted before, a FAT32 table contains 128 entries, this means (for allocated clusters, with contiguous files), that the very first entry in the very first sector of the table should have value:

01 00 00 00 (but it has not, because the first two entries are "markers or signatures")

and the last entry of the first sector will have value:

80 00 00 00 (as 0x80 = 128)

Second sector begins with:

81 00 00 00

Third sector begins with:

01 01 00 00

Fourth sector with:

81 01 00 00

Fifth sector with:

01 02 00 00

etc., etc.

in other words, normally a sector belonging to a FAT 32 table (representing an allocated cluster)  will begin with 01 or with 81.

 

I hope you are following me. :unsure:

 

On the files you posted inside sectors.zip:

  1. "sector from 487 to 587" begins with 01 (good)
  2. "sector238503" begins with 01 (good)
  3. "sectors from 238896 to 238995" starts with B9 :w00t: and the "01" can be found at offset 288/0x0120 (if you prefer all sectors on that file begin with either 39 or B9)

Can you check/recheck your image and the procedure you used to make that file?

 

Also (please again follow me) "sector from 487 to 587" begins with:

01 C4 00 00 , since 0xC401=50177 up to sector 486 there are 50176 entries, i.e. 50176/128=392 sectors of the FAT, to which you add the (63+32) = 95 sectors you get back the sector number 392+95=487

 

"sector238503" begins with:

01 A4 D1 01 , since 0x01D1A401=30516225, up to sector 238502 there are 30516224 entries. i.e. 30516224/128 238408 sectors + 95 = 238503

 

This means that sector 238503 still belongs to the first FAT table (which is good, or at least coherent with my previous calculations).

 

Now if you try taking a new copy of a 100 sectors around 238896 (and hopefully this new copy will have as first bytes either 01 or 81) we will be able to verify the calculations.

 

Explanation:

Setting temporarily aside the "strage "shift", the first value in "sectors from 238896 to 238995" is 39 0B 01 00 , which is 68409, and 68408/128=534.4375, i.e. sector 238896 should correspond to either sector 534+95=629 or to sector 535+95=630 which would give us a size for the FAT of either 238896-629=238267 or 238896-630=238266 which are evidently "wrong" as we have already made sure that sector 238503 belongs to the first FAT.

 

 

I cannot really think of anything (short of a strange controller issue of some kind OR a mistake you did when copying the sectors) that could justify the "shift" in that last file. 

 

Maybe it would be easier (if it is possible for you) if you could image first 95+2*238409+(say) 1000=477,913, let's round them to 488,000 sectors.

That will result in a 488,000*512=249,856,000 bytes file which should compress with zip (or with 7-zip with a slightly higher compression ratio) to something less than 100 Mb. (you may need to upload it to a file hosting like zshare or similar and post a link to it)

 

jaclaz

 

 



#24
bphlpt

bphlpt

    MSFN Addict

  • Member
  • PipPipPipPipPipPipPip
  • 1,798 posts
  • Joined 12-May 07
  • OS:none specified
  • Country: Country Flag

I would also suggest going back to the company you gave the disk to, and see if they might be a little more forthcoming as to what exactly they did to it. (And personally, I would never give them a disk again. :) )

 

Cheers and Regards


Posted Image


#25
nthnl

nthnl

    Newbie

  • Member
  • 17 posts
  • Joined 11-November 13
  • OS:Windows 7 x64
  • Country: Country Flag

Hello Jacklaz,

 

Indeed you are correct - the file that I uploaded is wrong :( . No idea actually how that happened as I used the same procedure -> select the block of text -> copy in to new file. I have done this again and now it seems to be correct. Let me know if you still need me to upload the 100mb file.

 

Note: I did the search on my device for the B9 F5 00 00 BA F5 00 00 and ideed it can be found at 586 and 238995.

 

 

Kind Regards,

Mihail Velikov

System Administrator

Attached Files


Edited by nthnl, 18 November 2013 - 07:22 AM.





0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users