At Wed, 13 Jun 2007 10:31:33 +0200, "christian nastasi" <[EMAIL PROTECTED]> wrote: > > [1 <multipart/alternative (7bit)>] > [1.1 <text/plain; ISO-8859-1 (7bit)>] > Hi all, > I'm working on the vfatfs translator and I'm trying to understand how it > should be merged with the fatfs one. > First of all I'm looking at the dir entries searching (diskfs_lookup_hard). > Some questions. > 1- What does mean the slot status COMPRESS in the dir.c? It seems that > should be used to choose to look for the LFN entry slots.
In dir.c, line 47 on: /* This means that there is enough space in the block, but not in any one single entry, so they all have to be shifted to make room. */ COMPRESS, Ie, the directory block has enough free space due to deleted entries that it can be used, but the space is fragmented, ergo the used space needs to be compressed. For example, say you need two directory entries for a long file name, and all entries in the block are used, except for two. Then we know the long file name will fit, but there are two possibilities: The free entries are next to each other, then we can use them directly, or they are separated, then one of the entries needs to be moved. Actually, the logic you see in the code comes from the ext2fs file system, and it may be more complex than necessary. IIRC, all dirents in FAT are of the same size. The ext2fs code can not make that assumption. So, there you have to move all entries inbetween to defragment. In FAT, one only needs to move as many entries as the space that needs to be freed. However, scanning for the free entries will still take time linear in the number of entries that are inbetreen. However, that work has already been done in dirscanblock, so one could store its result for later. When reading the code, imagine that dirents could have different size, to understand how and why it is written (also compare ext2fs/dir.c). In particular you will want to look at ext2fs' diskfs_direnter_hard, where you can see the defragmentation step. This is what could, in principle, be optimized further in fatfs, but I would suggest that you just copy that code for now and leave it at that for simplicity. > 2- The multiplexing between fat and vfat could be done in the > dirscanblock(), doesn't it? That's what I suggested before. > Here I want to know what the fatfs authors > intend to do with the COMPRESS status (is it for vfat LFN?). See above, and yes, it is for LFN support. > I suppose the fatnamematch() will be also multiplexed with a vfatnamematch > or whatever you want to call it. I wouldn't take this literally, but yes. Maybe have two functions, collectfilename and matchfilename. Thanks, Marcus _______________________________________________ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd