Re: file systems

[Andreas Schwab <schwab@issan.informatik.uni-dortmund.de>]

On Wed, 29 Dec 93 2:24:44 CST, ekl@sdf.lonestar.org (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.