Ralph Lange wrote...
> Another NFS@vxWorks question:
>
> Our (Unix) NFS server exports two disks: / and /mnt/s5
> There is a soft link in / that points to the other disk:
>
> > ls -al /usr
> 1 lrwxrwxrwx 1 root sys 7 Dec 30 12:27 usr -> /mnt/s5/
>
> Our IOCs mount the server's disks using nfsMountAll():
>
> -> nfsDevShow
> device name file system
> ----------- -----------
> / vwhost:/
> /mnt/s5 vwhost:/mnt/s5
>
> I create a directory that is writeable for the IOC
>
> drwxrwxr-x 2 lange epics 1024 Jun 23 11:50 /usr/IOC/Local/test
>
> When the IOC tries to open a file using the link it gets an error
>
> -> dbior > /usr/IOC/Local/test/test_a
> can't create output '/usr/IOC/Local/test/test_a'
> errno = 0xd (S_errno_EACCES)
>
> whereas it succeeds using the "real" directory name
>
> -> dbior > /mnt/s5/IOC/Local/test/test_a
> value = 0 = 0x0
>.
>.
>.
> Has anyone any explanation for this? (I suppose this is a bug in
> the vxWorks nfsLib...)
Sort of... Here's an excerpt from the VxWorks FAQ that addresses the
issue:
------------------------------
19. Why can't I do ".." at top level directories or NFS mount points?
Because, again, VxWorks does not really have a "filesystem" as most people
understand it. The top level directories are just implemented as device
driver "node", which is used to identify the ioDev associated with the
specific VxWorks "filesystem". Since there is no underlying filesystem
layer, the story ends there. When you're at the top of the directory
hierarchy within a given ioDev/filesytem, you simply cannot do "..".
------------------------------
20. Why do I have trouble using relative symbolic links with NFS?
See [Q: Why can't I do ".." at top level directories or NFS mount points?]
above. This is just another problem caused by the fact that a real filesystem
does not exist for VxWorks. NFS client implementation actually does implement
the symbolic links correctly, using lookup and readlink. The problem is
due to the fact that, for some relative links that use ".." or whatever, that
crosses over filesystems, VxWorks cannot have underlying subsystem that will
handle file pathname to device mapping.
Using absolute symbolic links work just fine (i.e. full path name from top).
------------------------------
Tim Mooney
Beamline Controls & Data Acquisition
Advanced Photon Source
- Replies:
- Re: NFS vxWorks Access Rights Ralph Lange
- Navigate by Date:
- Prev:
NFS vxWorks Access Rights Ralph Lange
- Next:
Re: NFS vxWorks Access Rights Ralph Lange
- Index:
1994
1995
1996
<1997>
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: NFS vxWorks Access Rights Ralph Lange
- Next:
Re: NFS vxWorks Access Rights Ralph Lange
- Index:
1994
1995
1996
<1997>
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|