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.

_________________
Software developer for Amiga OS3 and OS4.Develops for OnyxSoft and the Amiga using E and C and occasionally C++

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.

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.

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.

_________________
Software developer for Amiga OS3 and OS4.Develops for OnyxSoft and the Amiga using E and C and occasionally C++

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).

You are correct, the emulator specifically uses the ST_xxxx defined valuesfor 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_DirEntryTypefor old application compatibility.

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

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

Conversely, if using the new DOS calls with an old handler, they won'tunderstand the new dospackets and will respond with the same error codesas mentioned above. When that happens, the new DOS calls will fallbackto trying the old FIB style function calls internally, this implies the sameold limitations if this occurs.

So the moral to this story is that whenever possible, use the new DOS callsand 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 functionsanymore, so supporting them is quite pointless if they can be upgradedfor the new ExamineData based functions instead.

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 useof 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 limitationof 255 bytes for an object would be ok to also maintain DOSPacketcompatibility 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 thelatest dos/dos.h include file. These are defined as;

The support that I indicated uses the V54 utiliy.library UTF-8 <-> UCS4 Unicode conversion functions. The filesystems can't open disk basedlibraries (like locale.library) for obvious reasons, so the required functionsfor 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 thanchecking for a few characters in the low 7 bit ascii (<127) which also mapto 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.

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.