FAT programs not filling FAT tables

[Octacone]

Hello,

I've ran into a big problem. The programs I use for virtual HDD management don't want to work anymore, or at least they never have?
This is my setup: FAT 32 partitioned virtual HDD image that I put all the files on and that I use for testing.
So the problem is: when I try to copy a file called Stage_2.sys it gets copied internally but no file allocation table data is being provided, no FAT entries related to that file whatsoever?
Any ideas?

mcopy (mtools) -> same thing
kpartx -> same thing

[BenLunt]

Hi Octacone,

If I were to completely guess, without any more information, I would have to say that you are looking in the wrong place for the table and the table is indeed being written to.

Just my guess.

Ben
- http://www.fysnet.net/osdesign_book_series.htm

[Octacone]

@BenLunt

I don't think that can be the case. I have a program called "Active @ Disk Editor" that allows me to easily navigate around.
With just one click of a button I can go to standard filesystem locations (such as FAT tables).

[MichaelFarthing]

So the problem is: when I try to copy a file called Stage_2.sys it gets copied internally but no file allocation table data is being provided, no FAT entries related to that file whatsoever?

I'm struggling with this because it's not quite clear to me how much partial success your copy has had.

Please can you clarify exactly what you mean by "it gets copied internally" and how do you know this?
Is the FAT32 volume visible to Windows?
If so does the directory listing show the copied file or not?

I've use ActiveDisk too but find it needs a bit more guidance than I would expect. For example, the template pane can often be looking at a different bit of memory from the main hex display and the default template displayed is often very much an uninformed guess by the program. The user has to be quite alert to ensure an appropriate template is picked and that the hex display point matches the template display point and that both point to an appropriate place for the selected template.

[Octacone]

@MichaelFarthing

Okay so when I look inside the root directory there is a valid entry present, everything contained within the file can also be found at sector x and y (standard stuff), but there are no FAT entries present.
Btw I use Linux, not Windows. I am well aware of those issues, but they are just some minor bugs that can be worked around.
How am I supposed to follow the cluster chain when there is no one to follow?
Yes, Linux shows that file (inside its file manager app) just fine.

[iansjack]

I've got to agree with Ben - you are looking in the wrong place for the FAT. It is most unlikely that three separate methods of copying the file would produce identical errors.

[alexfru]

Okay so when I look inside the root directory there is a valid entry present, everything contained within the file can also be found at sector x and y (standard stuff), but there are no FAT entries present.
...
How am I supposed to follow the cluster chain when there is no one to follow?
Yes, Linux shows that file (inside its file manager app) just fine.

And just how do you know those "x and y (standard stuff)", especially when there's more than one "x"? And how do you know where the root directory or the file ends? To know that you'd need to access the cluster chain. If Linux is able to do it and you "observe" problems with several different tools, it's very likely the problem is actually in your code and not elsewhere. Somehow you aren't calculating the location correctly. You must be able to see the last cluster markers for the root directory and for the file (and all preceding clusters in the chain if the size is larger than one cluster).

Start with a clean FAT32-formatted disk image (no files, just the root dir). Look (with your hex editor?) for the two reserved entries for clusters numbered 0 and 1. Those should typically be 0x0F.FF.FF.F8 and 0x0F.FF.FF.FF. If your FAT32 root directory starts at cluster 2 (typical), then the next value should also be 0x0F.FF.FF.FF. Your calculations should give you the sector where you find these three values. I bet the are off by something.

P.S. If you don't find those two/three values anywhere, check with fatgen103.doc. The doc allows for different EOC values, there are reserved bits in FAT32 cluster values, etc etc.

[Octacone]

I am not doing anything manually. There is a button that says FAT (1), when I press it, it opens a sector which contains the FAT itself so I can take a look at it.
Yes I can see all the reserved entries. I am certain that my code works just fine, I followed the official documentation.

[iansjack]

I take it your stage2 is more than one cluster in size. Otherwise the FAT chain will just consist of the one entry FF FF FF 0F.

[Octacone]

Sure, it has more than 512 bytes. 821 bytes to be precise.

Edit: this is what my editor looks like:

[iansjack]

I would have thought that, on a hard disk, your clusters would be larger than just one sector.

[Octacone]

What are you trying to point out?
Are you saying that since a cluster is 4 KB in size I should load 8 contiguous 512 byte sectors one after another?
Wait, so a file will always span across 8 512 byte sectors, even if it is just 821 bytes long?

[iansjack]

Wait, so a file will always span across 8 512 byte sectors, even if it is just 821 bytes long?

Yes. This is basic stuff. Clusters and sectors are not the same. FATs record clusters, not sectors.

If your clusters are 4KBthen a 1-byte file will occupy 4KB on the disk.

[Octacone]

Thanks man!

I had an entirely different concept in my head, looks like I screwed something up. Guess I wasn't careful while reading...
Sorry for bothering you all, just a silly mistake.