Experimental Physics and
Industrial Control System

Vesna Samardzic-Boban <[email protected]> · Thu, 18 Apr 2013 10:50:06 +1000

Hello Ron, Tim,

1st   Glad to see you also have made/are making similar changes to saveData.c.
2nd  Yes, agree about using open() instead of creat() - that's what I have chosen as well.

It is also my understanding that my system set-up is not relevant here as creat() is part of the OS (iocLib.c) - Ron mentioned similar in the last paragraph of his email.
The NFS server is a CentOS 5.6 box - so far the vxWorks nfs client mounts/works well, no problems at all.

Vesna

________________________________________
From: Ron Sluiter [[email protected]]
Sent: Thursday, 18 April 2013 8:19 AM
To: Tim Mooney; Vesna Samardzic-Boban
Cc: [email protected]
Subject: Re: sscan/ saveData problem with RW permission, and not an NFS issue

Hello Vesna,

Two points...

1st, I checked this change into saveData.c
> #ifdef vxWorks
>     file= creat(tmpfile, 0640);
> #else
>     file= creat(tmpfile, O_RDWR);
> #endif
on March 15, 2012.  We, here at APS, have been using that change
ever since, but it has not yet made it into an "official" sscan module
release (i.e, it is not available from the sscan web page). I think that
explains why you are having problems and we are not.

2nd, I believe Andrew's suggest is the better modification, i.e.,
replace the creat() call with,

>     file = open(tmpfile, O_CREAT|O_RDWR|O_TRUNC, 0666);

As I understand it, the purpose of creating a file here is
verify R/W permissions. The above should be an OSI method
of doing that.

Ron

On 4/17/2013 10:36 AM, Tim Mooney wrote:
> Hi Vesna,
>
> If it were a bug in creat(), I'd expect the same behavior here with vxWorks
> 6.9, but Ron Sluiter verified that it works here.  Of course it may be that
> your 6.9 is differently configured.  If so, saveData's sensitivity to the
> difference might be good information to have, as more folks start using
> vxWorks 6.x.
>
> I'm concerned that there is something different about your system that might
> have hard-to-diagnose consequences later, and I think we should turn over a
> few more stones before just moving on.  I think open(..., O_CREAT, ...) is
> not exactly the same as creat().  It would succeed if the file already
> existed - perhaps because saveData lacks the ability to delete files - so it's
> not a bulletproof indicator that saveData can create a new file.
>
> Are you confident that you're using NFS?  vxWorks is pretty sneaky about
> silently falling back to netDrv if an NFS mount to the path it needs is not
> available.  But saveData is not tested with netDrv.  On vxWorks, saveData only
> works reliably with NFS.
>
> If you are using NFS, which version are you using?
>
> Tim
>
> ----- Original Message -----
>> From: "Vesna Samardzic-Boban"<[email protected]>
>> To: "Tim Mooney"<[email protected]>, "Andrew Johnson"<[email protected]>
>> Cc:[email protected]
>> Sent: Wednesday, April 17, 2013 4:56:27 AM
>> Subject: RE: sscan/ saveData problem with RW permission, and not an NFS issue
>>
>> Hi Tim and Andrew,
>>
>> Agree with Andrew it is a vxWorks bug in creat().
>> But it's easier (for me) to replace the line/creat() in saveData.c
>>      file= creat(tmpfile, O_RDWR);
>> with open() e.g.
>> #ifdef vxWorks
>>      file = open (tmpfile, O_CREAT | O_RDWR, 0666);
>> #else
>>      file = creat (tmpfile, O_RDWR);       /* if this is needed by
>>      other OS's*/
>> #endif
>> That way we do not depend on Wind River and their bug/fix.
>>
>> REgards Vesna
>>
>> ________________________________________
>> From: Andrew Johnson [[email protected]]
>> Sent: Wednesday, 17 April 2013 1:31 AM
>> To:[email protected]
>> Cc: Tim Mooney; Vesna Samardzic-Boban
>> Subject: Re: sscan/ saveData problem with RW permission, and not an
>> NFS issue
>>
>> Hi Tim,
>>
>> On 2013-04-16 Tim Mooney wrote:
>>> Thanks for the information.  I haven't tested sscan on vxWorks 6.9,
>>> though
>>> I'm told it works on vxWorks 6.8.  I don't think creat() uses
>>> O_RDRW as a
>>> file-permission mask, and I don't understand why open() would work
>>> while
>>> creat() does not.  I'm ok with making this change, but I'd like to
>>> understand it better first.
>> I don't think there's going to be any difference in the behavior
>> between
>> VxWorks 6.8 and 6.9.  This is one of those things that I believe Wind
>> River
>> got wrong very early in the life of VxWorks and it has never been
>> fixed
>> properly.  This is from the documentation for creat():
>>      The parameter mode is set to O_RDONLY (0), O_WRONLY (1), or
>>      O_RDWR (2)
>>      for the duration of time the file is open. On NFS and POSIX
>>      compliant
>>      file systems such as HRFS, mode refers instead to the UNIX style
>>      file
>>      permission bits.
>> They even say that the second argument has a different meaning on
>> different
>> file-systems, which means there is /no/ way to write code using this
>> routine
>> that works properly on all file-systems, because you have to know
>> what kind of
>> file-system it is to give the right parameter.
>> I recommend that creat() not be used in code that runs on vxWorks,
>> and that
>> all calls to it be replaced with the equivalent open() call instead.
>>   The
>> Linux man-page for creat() says:
>>      creat() is equivalent to open() with flags equal to
>>      O_CREAT|O_WRONLY|O_TRUNC.
>> You will also need to add the mode parameter 0666.
>> - Andrew
>> --
>> It is difficult to get a man to understand something, when his salary
>> depends upon his not understanding it. -- Upton Sinclair
>>
>> ________________________________________
>> From: Tim Mooney [[email protected]]
>> Sent: Wednesday, 17 April 2013 1:18 AM
>> To: Vesna Samardzic-Boban
>> Cc:[email protected]
>> Subject: Re: sscan/ saveData problem with RW permission, and not an
>> NFS issue
>>
>> Hi Vesna,
>>
>> Thanks for the information.  I haven't tested sscan on vxWorks 6.9,
>> though
>> I'm told it works on vxWorks 6.8.  I don't think creat() uses O_RDRW
>> as a
>> file-permission mask, and I don't understand why open() would work
>> while
>> creat() does not.  I'm ok with making this change, but I'd like to
>> understand
>> it better first.
>>
>> Tim
>>
>> ----- Original Message -----
>>> From: "Vesna Samardzic-Boban"
>>> <[email protected]>
>>> To:[email protected]
>>> Sent: Monday, April 15, 2013 8:52:30 PM
>>> Subject: sscan/ saveData problem with RW permission, and not an NFS
>>> issue
>>>
>>> Hi All,
>>>
>>>
>>> Found a problem as follows:
>>>
>>> Running a scan record on a vxWorks IOC and when entering 'File
>>> system' in scan_saveData.adl screen, an error message in the 'Save
>>> status' field follows:
>>> "RW permission denied !!!"
>>>
>>> At first I suspected NFS but after checking it found that my
>>> problem
>>> was in the sscan's saveData.c and/or VxWorks is 6.9
>>>
>>> Tried two versions of sscan, 2-6-6 and 2-8-2, they gave the same
>>> result as above. These two versions are same regarding the
>>> saveData.c and its function
>>>      checkRWpermission(char* path)
>>> and specifically the line
>>>
>>>      file= creat(tmpfile, O_RDWR);
>>>
>>> that creates test file "rix_" with file permissions 002 (because
>>> O_RDRW = 2)
>>> (O_RDRW is flag "Open for reading and writing" or File Access
>>> Options)
>>>
>>> The file permissions 002 become
>>> -------w-  in   terms of    rwxrwxrwx
>>> and hence the error "RW permission denied !!!"
>>>
>>> Found a solution by using vxWorks function open() instead of
>>> creat().
>>> open() - opens a file and optionally creates a file if it does not
>>> exist.
>>> open() - also offers a parameter for "mode" i.e. file permissions,
>>> which i set to 0x666 in the example below
>>>
>>>       file = open (tmpfile, O_CREAT | O_RDWR, 0666);
>>>
>>> Then scan data can be saved as expected.
>>>
>>> BTW
>>> saveData.c uses open() for creating 'subdirectory'.
>>>            fd = open (local_pathname, O_RDWR | O_CREAT,
>>>                             FSTAT_DIR | DEFAULT_DIR_PERM | 0775);
>>>
>>>
>>> Has anyone had similar problems ?
>>> Is this an sscan/saveData.c issue or vxWorks 6.9 issue (I do not
>>> have
>>> any other version of vxWorks) ?
>>> How about sscan/saveData on OS's other than vxWorks?
>>>
>>>
>>> Thanks Vesna
>>>
>>> P.S.
>>> In my vxWorks 6.9 and its ioLib.c, creat() does not offer file
>>> permissions (set to 0 as below):
>>> int creat
>>>      (
>>>      const char *name,           /* name of the file to create */
>>>      int         flag            /* file permissions */
>>>      )
>>>      {
>>>      return (ioCreateOrOpen (name, flag, 0, TRUE));
>>>      }
>> SUPPLIERS: As of 1 January 2013, the Australian Synchrotron Company
>> Ltd has changed its business name. However, the trading name will
>> remain Australian Synchrotron.
>> Please address all quotations and invoices to: Synchrotron Light
>> Source Australia Pty Ltd (SLSA), ABN: 18 159 468 256
>>

SUPPLIERS: As of 1 January 2013, the Australian Synchrotron Company Ltd has changed its business name. However, the trading name will remain Australian Synchrotron.
Please address all quotations and invoices to: Synchrotron Light Source Australia Pty Ltd (SLSA), ABN: 18 159 468 256

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System