OSDev.org

Rob wrote: This has the advantage that the driver code should be far less "complicated" to rename a directory. The downside is that if another process / thread is reading it could see files in the old directory before they are "moved".

"What do you mean, I have to change my AudioGrabber settings and re-name my entire mp3 collection to just so I can copy it to my flash drive? I'll just use FAT, thanks..."

   mov ecx,(256 * 2048) / 4            ;ecx = size of table in dwords
   mov edi,BOOTMEMCPUdataTable
   clr eax
   cld
.l1:   mov [gs:edi],eax
   add edi,4
   loop .l1

Rob wrote:Anyway, what about a volume label? I think Windows needs it. Not 100% sure if it is really required though.

Rob wrote:

• 1. It looks like it is a conscious decision to have only one date for a file. Perhaps it would be a good idea to have a create date as well? (I don't care for the access date which Windows also has, for example). That might be a piece of crucial information you want to give the receiver.
• 2.

  For the directory entry type, all other fields in the index entry except for the entry name must be ignored when the entry is read and filled with zeros when the entry is being written

  Shouldn't a directory have a (create, see point 1) modify date as well? I assume it can be renamed?

Rob wrote:Perhaps it would be wise to include guidelines/recommendations/algorithms in the spec to advice people that when a new file get's added or an existing file expanded the list of deleted files gets checked.

Candy wrote:

Despite this, it would be easy to make the "index area entries" 256 bytes long instead of 128 bytes long. That would make the maximum file name length 230 bytes.

What about making it stretchable entries? You just have a first byte/word/dword that indicates how many 64byte blocks it is and it can be any size. The entry placement algorithm is then exactly identical to the file placement algorithm, so you can use the same implementation or knowledge/experience and you can have infinite length filenames (at least, stretchable lengths). My main point is, you don't get arbitrary failures "file path too long" such as were common in DOS (with a limit of iirc 64 or 80 something characters).

Brendan wrote: You're right - I intend to reduce each "index area entry" to 64 bytes and then allow the file name to stretch over any number of sequential index area entries. I'm thinking of using 2 flags in the "entry flags" field, one to say that the file name is continued in the next entry and the other to say that the entry is a continuation of the previous entry. This means file names that are less than 30 bytes long will consume one entry, names that are less than 93 bytes long will take 2 entries, and a name that takes 63030 bytes will consume 1001 entries.

struct direntry {
  int blockcount:16; // think 8 would suffice
  struct other_info oi;
  char filename[enough];
};

It would be a nice touch if you could require the files to be in subdirectory-order

Kemp wrote:

It would be a nice touch if you could require the files to be in subdirectory-order

I'd imagine the constant rearranging would be very detrimental to a flash-based disk in this case.

Candy wrote:

Brendan wrote: You're right - I intend to reduce each "index area entry" to 64 bytes and then allow the file name to stretch over any number of sequential index area entries. I'm thinking of using 2 flags in the "entry flags" field, one to say that the file name is continued in the next entry and the other to say that the entry is a continuation of the previous entry. This means file names that are less than 30 bytes long will consume one entry, names that are less than 93 bytes long will take 2 entries, and a name that takes 63030 bytes will consume 1001 entries.

That's awfully close to the FAT patent. Also, it requires linking the entries. I would vote for making the entry itself variable-sized and just stretching it across one or more "dirent"-blocks.

struct direntry {
  char magicnumber   // Anything that can't be in a filename ('?', '*', etc)
  int blockcount:16; // think 8 would suffice
  struct other_info oi;
  char filename[enough];
};

Candy wrote:One other thing, what about dumping the idea of directory names being in the file name? It makes renaming so much harder and unreliable that I'm not sure it'll help. Also, searching through files will be not much harder. It would be a nice touch if you could require the files to be in subdirectory-order so that if you search through the tree that all files in a given directory are after the entry for that directory. That makes any search still linear time. Appending entries at the end ensures this for the simple ones, more complex ones could look at where the parent dir is and find a place to put it from there.

void *address;

bool check_for_entry(char *name) {
    for(address = index_area_start to index_area_end; step ENTRY_SIZE) {
       if( strcmp(address->name, name) == MATCH) return TRUE;
    }
    return FALSE;
}

bool delete_file(char *name) {
    if(check_for_entry(name) == FALSE) return FALSE;
    address->type = deleted;
    return TRUE;
}

bool write_file(char *name, void *data, int size) {
    void *temp1, temp2;

    delete_file(name);
    temp1 = data_area_end + size;
    temp2 = index_area_start - ENTRY_SIZE;
    if(temp1 > temp2) {
        if( compact() == FALSE) return FALSE;
        return write_file(name, data, size);
    }
    memcopy(data_area_end, data, size);
    temp2->start = data_area_end;
    temp2->end = temp1;
    temp2->size = size;
    temp2->timestamp = get_time();
    temp2->type = FILE;
    memcopy(temp2->name, name, strlen(name)+1 );
    data_area_end = temp1;
    index_area_start = temp2;
    return TRUE;
}

bool read_file(char *name, void *data, int max_size) {
    if(check_for_entry(name) == FALSE) return FALSE;
    size = address->end - address->start;
    if(size > max_size) return FALSE;
    memcopy(data, address->start, size);
    return 0;
}

Brendan wrote: For something like a digital camera using (memory mapped) flash memory, this is close to complete except for the "compact()" function (which would be a bit messy, but could also be optional). It's also "uncorruptable" in that a power failure at any point won't matter.

This level of simplicity died when we decided to have seperate/explicit entries for directories. Now you'd need to add some "does the directory entry exist" stuff to it, but it'd still be reasonably simple.

I'm almost tempted to make directories implicit again, so you can do "write_file("a/b/c/d/e/f/g/file.txt", data, size)" without caring if any of these directories exist or not. Still, doing one search to see if "a/b/c/d/e/f/g" is present won't slow things down much - it's only one linear search.

To seperate the file name from it's path, you'd need to search for the directory "g", then search for "f" and hope that "f" is the parent to "g", then search for "e" and hope that "e" is the parent to "f", etc. If during this recursive search you find out that the parent is wrong (e.g. if there's other directories elsewhere with the same names, like "oops/b/c/d/e/f/g") you'd need to start again searching from the first sub-directory (i.e. go back to searching for another "g" and do everything again). In this case the simplest possible implementation becomes slow, so you'd need to optimize it to improve those frequent searches and lose the simplicity.

dushara wrote:Would it be a good idea to keep 2 copies of the data area and index area size fields in your super block? (preferably over 2 sectors) and keep an incrementing counter.