fib_DirEntryType returns -1 for files on NFS-handler

Hi

Does anyone know if fib_DirEntryType = -1 has a special meaning, or is it just a bug in the "nfs-handler" filesystem driver?

This is what I can find in the SDK:
#define ST_ROOT 1
#define ST_USERDIR 2
#define ST_SOFTLINK 3 /* looks like dir, but may point to a file! */
#define ST_LINKDIR 4 /* hard link to dir */
#define ST_FILE -3 /* must be negative for FIB! */
#define ST_LINKFILE -4 /* hard link to file */
#define ST_PIPEFILE -5 /* for pipes that support ExamineFH */

-1 does not exist, but a macro indicates any negative number is a file:
#define FIB_IS_FILE(fib) ((fib)->fib_DirEntryType < 0)

Any thoughts? Do I have to implement a special case here? I'm handling links too, so can't just use this macro.

Thanks.

The FIB and its contents are long obsolescent. These days any DOS calls that use an FIB are emulated by DOS.

It may be too much work for an old existing program, but I really would suggest that you investigate replacing all the FIBs and their contents with current DOS calls like IDOS->ExamineDir() and IDOS->ExamineObject(). You'll find them much cleaner and faster.

To answer your question, take a look at include/dos.h (about half way down) for the new object types. The calls to ExamineDir() and ExamineObject() are described in Autodocs/dos.doc.

@Deniil

The solution seems simple enough to me. Just check if fib_DirEntryType is ST_LINKFILE first and then check with FIB_IS_FILE() if this is not the case, if you have to treat these types differently.

If you're programming for AmigaOS 4.x you really should use the ExamineData based functions though, as the FIB based ones are obsolete and have some limitations (no large files support or support for file names longer than 107 characters).

Also for modern vector port file systems the FIB based functions will be slower because they have to go through the packet emulator and since they are packet based there is also the added message round-trip time which is avoided when using the vector port API.

Thanks.

The program is unfortunately an old 68k program written in AmigaE. I develop on OS4 though, and people use it on OS4. But I'm stuck with fib.

I'll simply put in an exception for -1. The user must have reported the problem from a 68k system where the nfs-handler file system is broken since I would assume the OS4 emulator would/could not put -1 in there.

@Deniil

I wouldn't say it is broken. While it is recommended for file systems to use the ST_#? define values for fib_DirEntryType, any negative values should be interpreted as a file (as the FIB_IS_FILE() macro does) and any positive value as a directory with exception of ST_SOFTLINK which is kind of special (zero is IIRC ambiguous and should not be used in any situation).

@salass00

Yes, in general a zero value should mean "undefined", all known values should be non-zero.

@Deniil

You are correct, the emulator specifically uses the ST_xxxx defined values
for the fib_DirEntryType, with it being left as zero only if it's none of the
known defined types, after that is done, fib_Obsolete = fib_DirEntryType
for old application compatibility.

The only way you can get any other value from fib_DirEntryType is if
the dospacket was actually supported by the handler and it set that value.

The DOS emulation is generally invoked when the original handler
responds with a failure code and the secondary error code
ERROR_ACTION_NOT_KNOWN, then the new calls are used and the
FIB content initialised as best as possible from the ExamineData,
because of the old FIB structure limitations, the name will be truncated at
107 bytes, comments truncated at 79 bytes and file sizes are clamped
at 0xFFFFFFFE (4GB) regardless of how much larger they are.

Conversely, if using the new DOS calls with an old handler, they won't
understand the new dospackets and will respond with the same error codes
as mentioned above. When that happens, the new DOS calls will fallback
to trying the old FIB style function calls internally, this implies the same
old limitations if this occurs.

So the moral to this story is that whenever possible, use the new DOS calls
and support the new dospackets (or vectorport calls for filesystems)
so that you won't be hit with a bunch of compatibility penalties.

Very little remaining in the OS still calls the old (FIB based) DOS functions
anymore, so supporting them is quite pointless if they can be upgraded
for the new ExamineData based functions instead.

@colinw
Out of curiosity:

Does that mean OS4 supports filenames longer than 107 characters?

What about path length limitations? (e.g. volume:dir1/dir2/filename)

@ChrisH

Yes, 107 bytes was the limitation imposed by the FIB (FileInfoBlock) structure,
so, some older filesystems couldn't really support more. (79 for comments).

Since there is a second antique limitation, specifically caused by the use
of BCPL strings used mostly with the older DOSPackets, supporting a
single object name or comment string that is longer than 255 bytes is
problematic. DOS paths are not an issue of any length.

So, since I can't fix everything in one go, I decided that a minor limitation
of 255 bytes for an object would be ok to also maintain DOSPacket
compatibility and also bring us into a more modern era. (at least for now).

Therefore for OS4, and for the recent support of UTF-8 encodings,
the current defined recommended values to support are at the top of the
latest dos/dos.h include file. These are defined as;

MAX_DOS_FILENAME 255
MAX_DOS_COMMENT 255
MAX_DOS_SOFTLINK_TARGET 4000
MAX_DOS_PATH 4000

The last two were increased from 1K due to the recent support of UTF-8
encodings in DOS and some filesystems, as the worst case unicode
UTF-8 encoding requires 4 bytes in some Asian and other languages.

The latest NGFS filesystem, the RAM handler, the ENV handler and the
FUSE filesystems (where supported) are able to work with these values.

The dos.library has a queery function; IDOS->FileSystemAttr() that can
be called to queery individual filesystem limitations.

@colinw

Quote:
Sorry for drifting off-topic a bit but could you please elaborate on that? What kind of support are we talking exactly?

@trixie

DOS and the latest file systems (eg ram-handler, env-hander, NGFS) now can:

1. Store and use object names with characters that have the sign bit set (eg UTF-8 character sequences);
2. Compare strings of 1-4 characters and give the proper results ("<", "=" or ">").

There may be more but those come to mind. As yet we do not have any means to display UTF-8 characters. That requires a rewrite of a large part of graphics.library.

@trixie

The support that I indicated uses the V54 utiliy.library UTF-8 <-> UCS4
Unicode conversion functions. The filesystems can't open disk based
libraries (like locale.library) for obvious reasons, so the required functions
for handling UTF-8 and Unicode were added to utility.library so to be
available early for other kickstart modules.

As far as DOS goes, it does not actually assume any encoding other than
checking for a few characters in the low 7 bit ascii (<127) which also map
to the same unicode values. DOS has to occasionally look for \n \r : /
(newline, carriage returns, colons and slashes) for its normal operation,
so it doesn't make assumptions about anything else anymore, so it can
transparently handle UTF-8 encodings now.

@tonyw, @colinw

Thank you both for the explanation.

Thanks for the info! FIB is really totally outdated...

@Deniil

Just as an aside, the old way with ExamineAll(), ExamineNext(), etc was slow and cumbersome to implement and caused duplication of code in file systems.

The way it works now with vecor-based file systems is that (for example) an ExamineDir() call from DOS causes the file system to scan the complete directory and make up a List with a Node for each Object in the directory. That list is then returned to DOS, which handles the search criteria as specified by the caller. There is now only a single call to the file system and the directory is scanned just the once. You don't have to (and can't) lock a directory any more since the scan is carried out by the file system and is effectively atomic.