lkml.org 
[lkml]   [1997]   [Jul]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: FAT/VFAT/FAT32 reimplimintation...
On Sun, 20 Jul 1997, James Mastros wrote:
> I'm not going to support umsdos/uvfat (or it will be dead last on my
> priority list) because I don't use it.
[...]

Ahh... now I see (both what ppl were saying to me, and myself.

The primary resason I'm not supporting umsdos/uvfat is that it is, frankly,
a dirty hack.
I don't want to have anything that I am not 100% cool with. I'll see if
the reserved fields in the directory entry structure look safe, and if so,
a userspace program can convert umsdos to fatish.

On Mon, 28 Jul 97, Andreas Schwab wrote:
> Empty files don't have a cluster, and thus no cluster number.

Yeha. How about this:
The inode of a file is the cluster it's directory entry (the SFN) is in *
(32*16 <the length of a FAT directory entry>) + the # of entries in it is.
I don't think that will ever repeat (over +J), but I havn't done the math
yet. (Don't worry about cluster 0 or 1, they are always FATs anyway)
That should work, since fatish will never support hard-links (it is obvious
how it should be implemented, but every fsck for DOS (chkdisk, norton disk
doctor, scandisk) I have seen reports mutiple files with the same starting
cluster as errors.
Basicly, if your root directory starts at cluster 85 (hit two random number
keys, incase you wondered), the first file (not "." or "..". those don't
exist in \. But due to the majic of dcache, I don't care) on your hard
drive would be inode number 85*32*16+0=21760. The root directory, BTW,
would be inode 1. Why? It's easy to find that way.

-=- James Mastros



\
 
 \ /
  Last update: 2005-03-22 13:40    [W:0.042 / U:0.184 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site