Experimental Physics and Industrial Control System
Folks,
I am having a very weird problem with deleting files from vxWorks. I am
running Tornado 2.0 on an MV167, and the boot host/NFS file server is Redhat
Linux. The problem is that if my current vxWorks path does not include any
symbolic links on the Linux machine then everything is fine, I can create,
read and delete files fine. The directory permissions, NFS exports and
UID/GID are all set up to allow this. The paths I am using are all on the
same file system.
However, if the vxWorks path is defined to include a symbolic link on the
Linux machine then I can create and read files, but I cannot delete them.
Here is an example. On my Linux machine "/home/epics/support" is a real
directory, while "home/epics/current" is a symbolic link to "support" in the
same directory, i.e. "/home/epics".
*** cd to the "real directory"
ioc13ge1> cd "/home/epics/support/CARS/iocBoot/ioc13ge1"
value = 0 = 0x0
*** Create a file
ioc13ge1> date > junk
value = 32 = 0x20 = ' '
*** Read the file
ioc13ge1> copy "junk"
Aug 29, 2001 22:28:19.524808659
value = 0 = 0x0
*** Delete the file
ioc13ge1> remove "junk"
value = 0 = 0x0
All is well. However, now cd to the same path but with a symbolic link:
ioc13ge1> cd "/home/epics/current/CARS/iocBoot/ioc13ge1"
value = 0 = 0x0
ioc13ge1> date > junk
value = 32 = 0x20 = ' '
ioc13ge1> copy "junk"
Aug 29, 2001 22:28:49.808140781
value = 0 = 0x0
ioc13ge1> remove "junk"
value = -2 = 0xfffffffe = clientQ + 0xff8aaa36
I can create and read the file fine, but the "remove" command fails with -2.
Why? The vxWorks documentation says that "remove" either returns OK (0) or
ERROR (-1). However, it is returning -2.
>From other NFS clients (e.g. a Sun) with the same UID/GID I can delete the
files fine whether my path is the real directory or the symbolic link. Here
is the output from a Sun NFS client:
chemmat5> cd /home/epics/support/CARS/iocBoot/ioc13ge1
/home/epics/support/CARS/iocBoot/ioc13ge1
chemmat5> date > junk
chemmat5> rm junk
chemmat5> cd /home/epics/current/CARS/iocBoot/ioc13ge1
/home/epics/current/CARS/iocBoot/ioc13ge1
chemmat5> date > junk
chemmat5> cat junk
Wed Aug 29 22:40:50 CDT 2001
chemmat5> rm junk
Is this a problem with vxWorks, Linux or both?
Thanks,
Mark Rivers
- Replies:
- Re: Weird file access problem with vxWorks Ernest L. Williams Jr.
- Re: Weird file access problem with vxWorks Steven Hartman
- Navigate by Date:
- Prev:
Re: AllenBradley PLC via ethernet Kay-Uwe Kasemir
- Next:
Re: alarm handler confusion (and solution) 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: AllenBradley PLC via ethernet Kay-Uwe Kasemir
- Next:
Re: Weird file access problem with vxWorks Ernest L. Williams Jr.
- 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