OSDev.org

I'm not sure where to post this... I've searched the forum and turned up some topics concerning SFS, but as far as I can tell, this issue has not been reported yet.

The issue is the following.

SFS Specification wrote: All names must end with a null character (0x0000).

This means that the zero terminator is part of the file/directory name. However,

SFS Specification wrote: There are 9 different types of index area entries:
<snip>
* Continuation Entry (any value between 0x20 and 0xFF inclusive)

SFS Specification wrote: Because bytes with values less than 32 aren't possible within directory names and file names, it is possible to determine if an entry is a continuation entry or any other type of entry by checking the first byte of the entry. If the first byte is below 0x20 the entry is not a continuation entry, and if the first byte is above or equal to 0x20 then it must be a continuation entry.

I've found that creating a directory or file whose full path (including the leading '/' character and excluding the zero terminator byte) is of length (64n+54) for directories or (64n+30) for files, leads to creating an excess continuation entry whose sole purpose is to store a single 0x00 byte, breaking the constraints on the Continuation Entries.

Currently I can see no workaround this issue, except for modifying the specification so that in these cases an excess continuation entry must not be created. This results in slightly more complicated code (you can no longer determine the length of a file using strlen or similar means, but have to use strnlen or equivalent function), but doing so removes the contradiction from the specification.

Has anyone come across this yet?



I've started implementing SFS, which I hope will be useful to anyone wishing to implement this file system and at some point in the future could be used as a reference implementation. The code is available at https://code.google.com/p/sfstools/ . I'm using the SFS draft at http://dimensionalrift.homelinux.net/co ... k/sfs.html as it is more complete than the one in the OSdev wiki.
I've come across some more ambiguities in the specification.
1. Do data block numbers for a file include the number of blocks in the reserved area, or is block number zero at the very start of the data area? This is not stated explicitly. I've interpreted it as if block number zero was indeed the first block of the data area.
2. In section Index Area Format, the graphic representation of "Continuation entry for file entry 4" is incorrect. It should be at least adjacent to its base file entry. Also the numbering of files is misleading (should be the reverse).
3. The specification indicates the Volume Identifier as the "first" entry. However, this would place the continuation entries before (closer to the start of the volume than) their base file/directory entry, removing the ability to simply strcmp() your way through the index are to locate a specific file/directory. I've interpreted the specification as if the Starting Marker was the "first" entry.

Currently I can see no workaround this issue, except for modifying the specification so that in these cases an excess continuation entry must not be created. This results in slightly more complicated code (you can no longer determine the length of a file using strlen or similar means, but have to use strnlen or equivalent function), but doing so removes the contradiction from the specification.

A single null character does not aversely affect the index - it doesn't map to any one other index type (one should look for a 0x10 byte at that location). The better solution is to define continuation entries as starting with either 0x20+ or 0x00.

1. Do data block numbers for a file include the number of blocks in the reserved area, or is block number zero at the very start of the data area? This is not stated explicitly. I've interpreted it as if block number zero was indeed the first block of the data area.

I've checked my implementation, and the reverse holds for me: all offsets are relative to the start of the partition (0 = superblock), mainly based on the observation that the unusable markers have the same descriptive text as far as their location goes (and in practice, those areas can be located anywhere in the reserved, data, or index area, and not be limited to the data section). It also has the additional advantage of only having to add the partition's offset (if any) to the address, and not having to get and add the reserved address offset, creating an uniform addressing system. The additional advantage is that the reserved area can be resized without having to rewrite the entire index. As far as ambiguities are concerned, yes it should be fixed.

2. In section Index Area Format, the graphic representation of "Continuation entry for file entry 4" is incorrect. It should be at least adjacent to its base file entry. Also the numbering of files is misleading (should be the reverse).

Other than the typo (will be fixed shortly), the table is correct - the index grows downwards. For each added file, the index grows, and the new entry is added at the bottom. The result is that the first file is at the very end of the disk, and the last file is closer to the start of the disk.

3. The specification indicates the Volume Identifier as the "first" entry. However, this would place the continuation entries before (closer to the start of the volume than) their base file/directory entry, removing the ability to simply strcmp() your way through the index are to locate a specific file/directory. I've interpreted the specification as if the Starting Marker was the "first" entry.

(Duplicate of #2) The index is a stack growing down. Items on the stack needs not always be the same size. Continuation markers are just a trick to "hide" larger entries.

Combuster wrote:A single null character does not aversely affect the index - it doesn't map to any one other index type (one should look for a 0x10 byte at that location). The better solution is to define continuation entries as starting with either 0x20+ or 0x00.

It maps to an undefined index entry type, which may be replaced with an unused entry (0x10) by any conforming implementation at its own discretion... which should not be the case. Redefining the continuation entries as starting with 0x20+ or 0x00 would indeed solve the problem, but I still think removing the trailing zero byte in this case is simpler, plus you gain an additional index area entry.

Combuster wrote:I've checked my implementation, and the reverse holds for me: all offsets are relative to the start of the partition (0 = superblock), mainly based on the observation that the unusable markers have the same descriptive text as far as their location goes (and in practice, those areas can be located anywhere in the reserved, data, or index area, and not be limited to the data section). It also has the additional advantage of only having to add the partition's offset (if any) to the address, and not having to get and add the reserved address offset, creating an uniform addressing system.

I see, this is simpler (which is better)... Wait, did you say "unusable regions in the middle of the index area"?

Combuster wrote:Other than the typo (will be fixed shortly), the table is correct - the index grows downwards. For each added file, the index grows, and the new entry is added at the bottom. The result is that the first file is at the very end of the disk, and the last file is closer to the start of the disk.

Combuster wrote:The index is a stack growing down. Items on the stack needs not always be the same size. Continuation markers are just a trick to "hide" larger entries.

I see... Time for some rewrite, I guess.

I found your VDisk implementation when I was searching the forums just now, and wanted to try it out, but the executables need some obscure Visual Basic stuff which I don't have... Too bad.

ru2aqare wrote:I found your VDisk implementation when I was searching the forums just now, and wanted to try it out, but the executables need some obscure Visual Basic stuff which I don't have... Too bad.

It works out of the box on my computer, but since you have one of those bad versions of windows that doesn't even come with the standard runtime like they said they did, I have added an installer to the downloads.

Combuster wrote:It works out of the box on my computer, but since you have one of those bad versions of windows that doesn't even come with the standard runtime like they said they did, I have added an installer to the downloads.

Thanks, I got it to work. I simply extracted the files from the installation and got a copy of msvbvm50 off the net. Will try interoperability with my SFS implementation.