[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: file systems
On Wed, 29 Dec 93 2:24:44 CST, email@example.com (Evan K. Langlois) said:
|> Anyway, I noticed that loaded file systems return a -33 and not a -34
|> when a non-existing path is accessed. I haven't seen a fix in th 1.09
|> diffs, but its definately a bug (its also why STZIP doesn't create folders).
Well, it's a bug in STZIP.
|> Now, I looked at the MiNT code, and decided that didn't help since it
|> looked fine. I looked at the ramfs code, and noticed that the "lookup"
|> function that "relpath2cookie" was calling didn't differenciate between
|> a directory or a file. So, when the name wasn't found, it returned -33,
|> and I would assume that minixfs does the same thing (since it too returns
|> -33 instead of -34 from the relpath2cookie call). Now, what I'd like to
|> know, is how the filesystem can determine if the name its looking for is
|> a directory or filename? And if it can't then shouldn't the MiNT kernel
|> change a -33 (EFILNF) to -34 (EPTHNF) when the name being looked-up is
|> a directory?
I think using EFILNF is the right thing to do. At least it is
consistent with the meaning of ENOENT on Unix. There is also ENOTDIR
which is returned if a path component exists but is not a directory. I
think this corresponds to EPTHNF, and this is what MiNT returns in
this case. Note that GEMDOS (i.e. tosfs) works the same.
|> Also, before my absense everyone seemed to be talking about the Fseek
|> differences. All the filesystems seem to handle it differently. The
|> procfs has some stuff changed I think, but in any case, ramfs code or stzip
|> needs to be changed (was this already done? Which way is correct?)
The correct way is to always *add* the offset to the starting point
(start of file, current position or end of file). Note that a
positive offset with SEEK_END is meaningfull, e.g. on MinixFS or RamFS.