🚀 go-pugleaf

Submitted-by: jason@cnd.hp.com (Jason Zions)

>Given a more-or-less POSIX-compliant system, with multiple filesystem types
>(e.g., a "normal" unix filesystem, NFS, and DOS, all mounted at the same
>time), does anyone have any ideas what, oh, symlink() should return when
>attempted on a filesystem that does not support it?  For various reasons, I
>kinda like EINVAL, but I did want to see if anyone else had any ideas, or if
>someone could come up with a reference for a "definitive" posix-compliant
>answer.

The definitive answer will appear in the 1003.8 Transparent File Access
standard, when that is completed. (Draft 4 is out for mock ballot and will
be received in the first mailing; mine came today.) Join the ballot group
(opening soon) and have your say.

The specific example of symlink() is not addressed in 1003.8 since symbolic
links do not appear in 1003.1-1990 / IS 9945-1:1990.

The 1003.8 working group has proposed, in draft 4, adding a new error
EOPNOTSUPP which is used to indicate that the action has been requested on a
file accessed over some mechanism which does not support that action.
Overloading EINVAL was investigated and rejected; see the rationale. In some
cases an already-defined error could be unambiguously used; for example,
link() could return EMLINK since the access mechanism may support
LINK_MAX==1 only.

Jason Zions
Chair of, but not speaking on behalf of, P1003.8

Volume-Number: Volume 22, Number 126