Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
66 user(s) are online (50 user(s) are browsing Forums)

Members: 0
Guests: 66

more...

Headlines

 
  Register To Post  

fib_DirEntryType returns -1 for files on NFS-handler
Quite a regular
Quite a regular


See User information
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.

Software developer for Amiga OS3 and OS4.
Develops for OnyxSoft and the Amiga using E and C and occasionally C++
Go to top
Re: fib_DirEntryType returns -1 for files on NFS-handler
Quite a regular
Quite a regular


See User information
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.

cheers
tony
Go to top
Re: fib_DirEntryType returns -1 for files on NFS-handler
Just can't stay away
Just can't stay away


See User information
@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.

Go to top
Re: fib_DirEntryType returns -1 for files on NFS-handler
Quite a regular
Quite a regular


See User information
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.

Software developer for Amiga OS3 and OS4.
Develops for OnyxSoft and the Amiga using E and C and occasionally C++
Go to top
Re: fib_DirEntryType returns -1 for files on NFS-handler
Just can't stay away
Just can't stay away


See User information
@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).

Go to top
Re: fib_DirEntryType returns -1 for files on NFS-handler
Quite a regular
Quite a regular


See User information
@salass00

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

cheers
tony
Go to top
Re: fib_DirEntryType returns -1 for files on NFS-handler
Just popping in
Just popping in


See User information
@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.


Go to top
Re: fib_DirEntryType returns -1 for files on NFS-handler
Home away from home
Home away from home


See User information
@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)

Author of the PortablE programming language.
Go to top
Re: fib_DirEntryType returns -1 for files on NFS-handler
Just popping in
Just popping in


See User information
@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.


Go to top
Re: fib_DirEntryType returns -1 for files on NFS-handler
Just can't stay away
Just can't stay away


See User information
@colinw

Quote:
for the recent support of UTF-8 encodings

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

The Rear Window blog

AmigaOne X5000 @ 2GHz / 4GB RAM / Radeon RX 560 / ESI Juli@ / AmigaOS 4.1 Final Edition
SAM440ep-flex @ 667MHz / 1GB RAM / Radeon 9250 / AmigaOS 4.1 Final Edition
Go to top
Re: fib_DirEntryType returns -1 for files on NFS-handler
Quite a regular
Quite a regular


See User information
@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.



cheers
tony
Go to top
Re: fib_DirEntryType returns -1 for files on NFS-handler
Just popping in
Just popping in


See User information
@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.

Go to top
Re: fib_DirEntryType returns -1 for files on NFS-handler
Just can't stay away
Just can't stay away


See User information
@tonyw, @colinw

Thank you both for the explanation.

The Rear Window blog

AmigaOne X5000 @ 2GHz / 4GB RAM / Radeon RX 560 / ESI Juli@ / AmigaOS 4.1 Final Edition
SAM440ep-flex @ 667MHz / 1GB RAM / Radeon 9250 / AmigaOS 4.1 Final Edition
Go to top
Re: fib_DirEntryType returns -1 for files on NFS-handler
Quite a regular
Quite a regular


See User information
Thanks for the info! FIB is really totally outdated...

Software developer for Amiga OS3 and OS4.
Develops for OnyxSoft and the Amiga using E and C and occasionally C++
Go to top
Re: fib_DirEntryType returns -1 for files on NFS-handler
Quite a regular
Quite a regular


See User information
@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.

cheers
tony
Go to top

  Register To Post

 




Currently Active Users Viewing This Thread: 1 ( 0 members and 1 Anonymous Users )




Powered by XOOPS 2.0 © 2001-2023 The XOOPS Project