Experimental Physics and
Industrial Control System

"Ernest L. Williams Jr." <[email protected]> · Thu, 30 Aug 2001 07:57:44 -0400

Hi Mark,

I am able to reproduce the problem both on RH 7.0 Linux and Solaris 8.
Also, I am using Tornado 2.0.2 and an MVME2101 (powerPC) IOC.

I am not sure but suspect vxWorks is the problem.

Thanks,
*******************************************
Ernest L. Williams Jr.
SNS Control Systems Group, ORNL
701 Scarboro Rd., MS 6473
Oak Ridge, TN 37830
Phone 865-241-9071
e-mail: [email protected]
Fax 865-241-6739
******************************************
----- Original Message -----
From: "Mark Rivers" <[email protected]>
To: <[email protected]>; <[email protected]>; <[email protected]>
Sent: Wednesday, August 29, 2001 11:46 PM
Subject: Weird file access problem with vxWorks

> 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
>

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System