Click here to go to the forum index Click here for the home page
 
Author Message

<  TAP and patch development  ~  Topfield filesystem: finding number of directory entries

Page 1 of 1
mhw
Posted: Fri Mar 05, 2010 3:46 pm Reply with quote
Joined: 22 Aug 2005 Posts: 20
I'm working on some code to decode the Topfield filesystem and I'm a bit puzzled over how we're supposed to work out how many directory entries are being used in a directory cluster, other than by scanning through the whole cluster and ignoring the ones with 0xff as the first byte. I've got Firebird's Internal Information document, but it doesn't seem to cover this.

Here's an example of the ProgramFiles directory entry:

Code:
00131980  f2 00 00 00 00 00 00 00  00 00 00 03 00 00 00 b5  |................|
00131990  00 13 17 00 50 72 6f 67  72 61 6d 46 69 6c 65 73  |....ProgramFiles|
001319a0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
001319f0  00 00 00 00 00 00 00 00  00 00 00 00 c2 00 00 00  |................|


from which I can work out that it's a directory entry (the 0xf2 at the start), there's no timestamp (the next 7 bytes), and the contents of the ProgramFiles directory is in cluster 3 (the next 4 bytes).

The next 4 bytes are described in the doc as 'Filesize, number of clusters (S1)', but the value of 0xb5 doesn't seem to make sense so I'm assuming it to be inaccurate and that directories only occupy 1 cluster.

Then the next 4 bytes are supposed to be the 'Number of unused sectors in the last cluster in bytes (S2)', but this value (0x131700) is too large - ProgramFiles on this disk has at least 28 directory entries, so I'd have expected this field to be 0x130a00 instead.

Finally, the 2 bytes at the end of the directory entry are supposed to be 'Number of bytes in the last sector (mod 0x200) (S3)', but here they are zero and so don't contribute to the file size either.

These values seems to be valid for files, and the 'unused bytes in root directory' field in the superblock also seems to be accurate. But for directories other than root, is there a way to work out how many directory entries to look at, or do I need to scan the whole cluster in the worst case?

Cheers,

-Mark.

_________________
TF5800, IA On, TS On, F/W: MS6 Recommended F/W 12/9/2009 +BmCbCfCtEvEzIPePfPsRtUUuVb
TAPs: EPG2MEI v0.96; TF5000 Display v1.53; EIT Sub v0.6; Font Manager 1.0d; Extend v1.7; MyStuff 6.1; SecCache (UK) v0.4; MyInfo B4.1a;
Sig generated by MyInfo on 11/1/10
View user's profile Send private message
R2-D2
Posted: Fri Mar 05, 2010 4:03 pm Reply with quote
Frequent contributor Joined: 18 Dec 2006 Posts: 12148
The correct procedure is roughly what you have described: the "file size" is the size of the directory. Divide this by 128 and you have the number of directory entries. However, for a directory the "number of unused sectors" is actually the "unused bytes" for the directory (and the "bytes in last sector" is not used).

_________________
Troubleshooting -- User Manual -- Dark Side of the Matrix: Firmwares and Patches
View user's profile Send private message Visit poster's website
mhw
Posted: Fri Mar 05, 2010 4:30 pm Reply with quote
Joined: 22 Aug 2005 Posts: 20
Hmm. Ok, the disk I'm working with has 2444 sectors per cluster, so I'd expect the directory size to be given by

0xb5 (clusters, S1) * 2444 * 512 - 0x131700 = 0xd6ce100

but that's ridiculous - there's no way a directory uses 200Mb

so, if we replace the 0xb5 with 1 cluster as that seems more likely:

1 * 2444 * 512 - 0x131700 = 0x100

0x100 / 128 = 2 directory entries, which is only enough for '.' and '..'

In fact, the value of 0x131700 is consistent across all the directory entries in the root directory apart from __ROOT__ (which has the correct value and is consistent with the value in the superblock).

Hmm, inspiration just struck - there are actually two directory entries for each directory, aren't there: one in the parent directory and one as the first entry of the directory itself (with the name '.'). The size fields at the start of the directory look like they might be accurate. Is that the right place to be looking, rather than the entry in the parent directory?

Cheers,

-Mark.

_________________
TF5800, IA On, TS On, F/W: MS6 Recommended F/W 12/9/2009 +BmCbCfCtEvEzIPePfPsRtUUuVb
TAPs: EPG2MEI v0.96; TF5000 Display v1.53; EIT Sub v0.6; Font Manager 1.0d; Extend v1.7; MyStuff 6.1; SecCache (UK) v0.4; MyInfo B4.1a;
Sig generated by MyInfo on 11/1/10
View user's profile Send private message
R2-D2
Posted: Fri Mar 05, 2010 8:25 pm Reply with quote
Frequent contributor Joined: 18 Dec 2006 Posts: 12148
mhw wrote:
if we replace the 0xb5 with 1 cluster as that seems more likely:
I forgot to answer that bit (sorry!): the system does the calculation but then maxes it out to the maximum number of entries in a single cluster (i.e. bigger disks can have bigger directories). The reason for this is maybe because of a bug elsewhere in the firmware: it doesn't update the used clusters field properly for sub-directories. A VF&F will (attempt to) fix all of them, and I have suspicions that this is one way in which stuff can get lost... Sad

_________________
Troubleshooting -- User Manual -- Dark Side of the Matrix: Firmwares and Patches
View user's profile Send private message Visit poster's website
mhw
Posted: Fri Mar 05, 2010 9:47 pm Reply with quote
Joined: 22 Aug 2005 Posts: 20
I'm now thinking that size information in the 128-byte directory entry in the parent directory isn't to be trusted, and it's actually the directory entry at the start of the directory cluster (the one for '.') which is kept up to date. This seems to be correct for the directories in the root of the disk I'm looking at anyway - I'll see whether I'm right when I recurse through the subdirectories!

From what I can see, I'd suspect that the 'Number of unused sectors in the last cluster in bytes' field in the parent directory is initialised when the directory is first created and then never changed again. It has the value 0x131700 for all the subdirectory entries I've looked at apart from one, and that one is a directory that MyStuff has moved into the Recycle Bin.

The 'Number of Clusters' field in the parent directory looks like it starts out being 1 when a new directory is created, as you'd expect, but its value gets updated. Its value seems to have some kind of relation to the amount of stuff in the subdirectory (for example, DataFiles has it set to 0x15a10 while ProgramFiles has 0xb5).

-Mark.

_________________
TF5800, IA On, TS On, F/W: MS6 Recommended F/W 12/9/2009 +BmCbCfCtEvEzIPePfPsRtUUuVb
TAPs: EPG2MEI v0.96; TF5000 Display v1.53; EIT Sub v0.6; Font Manager 1.0d; Extend v1.7; MyStuff 6.1; SecCache (UK) v0.4; MyInfo B4.1a;
Sig generated by MyInfo on 11/1/10
View user's profile Send private message
R2-D2
Posted: Fri Mar 05, 2010 10:06 pm Reply with quote
Frequent contributor Joined: 18 Dec 2006 Posts: 12148
mhw wrote:
I'm now thinking that size information in the 128-byte directory entry in the parent directory isn't to be trusted, and it's actually the directory entry at the start of the directory cluster (the one for '.') which is kept up to date.
OMG my headache and giving blood has done me in today! I should also have answered that it's the root "." entry that is the one that contains the size of the sub-directory's entries. The named entry (in the parent directory) is, I think, meant to be keeping track of the disk usage of the sub-directory's contents -- as you've noticed it isn't actually maintained properly at all, but a VF&F will update the cluster usage to be accurate (at that point). I imagine that Topfield (or whoever wrote the code [maybe Nec?]) decided to not to fully implement this aspect because it would be an intensive, recursive process.

The cluster usage for the "." entry should always be 1 (with the "bytes free" starting at one whole cluster). Trying to add more entries than a single cluster will allow is dangerous, and maybe a little too easy on the original small disks (with lots of MP3 files).

_________________
Troubleshooting -- User Manual -- Dark Side of the Matrix: Firmwares and Patches
View user's profile Send private message Visit poster's website

Display posts from previous:  

All times are GMT + 1 Hour
Page 1 of 1

Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum