EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  <20012002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  <20012002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Weird file access problem with vxWorks
From: Mark Rivers <[email protected]>
To: "'[email protected]'" <[email protected]>, "'[email protected]'" <[email protected]>, "'[email protected]'" <[email protected]>
Date: Wed, 29 Aug 2001 22:46:29 -0500
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  <20012002  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  <20012002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 10 Aug 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·