home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / v22 / 126 / text0000.txt < prev   
Encoding:
Text File  |  1991-03-07  |  1.4 KB  |  32 lines
  1. Submitted-by: jason@cnd.hp.com (Jason Zions)
  2.  
  3. >Given a more-or-less POSIX-compliant system, with multiple filesystem types
  4. >(e.g., a "normal" unix filesystem, NFS, and DOS, all mounted at the same
  5. >time), does anyone have any ideas what, oh, symlink() should return when
  6. >attempted on a filesystem that does not support it?  For various reasons, I
  7. >kinda like EINVAL, but I did want to see if anyone else had any ideas, or if
  8. >someone could come up with a reference for a "definitive" posix-compliant
  9. >answer.
  10.  
  11. The definitive answer will appear in the 1003.8 Transparent File Access
  12. standard, when that is completed. (Draft 4 is out for mock ballot and will
  13. be received in the first mailing; mine came today.) Join the ballot group
  14. (opening soon) and have your say.
  15.  
  16. The specific example of symlink() is not addressed in 1003.8 since symbolic
  17. links do not appear in 1003.1-1990 / IS 9945-1:1990.
  18.  
  19. The 1003.8 working group has proposed, in draft 4, adding a new error
  20. EOPNOTSUPP which is used to indicate that the action has been requested on a
  21. file accessed over some mechanism which does not support that action.
  22. Overloading EINVAL was investigated and rejected; see the rationale. In some
  23. cases an already-defined error could be unambiguously used; for example,
  24. link() could return EMLINK since the access mechanism may support
  25. LINK_MAX==1 only.
  26.  
  27. Jason Zions
  28. Chair of, but not speaking on behalf of, P1003.8
  29.  
  30. Volume-Number: Volume 22, Number 126
  31.  
  32.