[Info-vax] OpenVMS - file selection abnormally with Copy / Rename or user ignorance?

[Louis Krupp]

On Fri, 27 Mar 2015 20:02:18 -0700 (PDT), IanD
<iloveopenvms at gmail.com> wrote:

>I am not sure if this is a bug or my lack of understanding, possibly the later
>
>OS version: 7.3-2
>Facility: RMS, called by copy or rename. Backup does not experience the same error
>Structure: ODS2
>
>I have a directory with 10's of thousands of small files (VMS is painfully slow dealing with them, but that's another matter)
>
>The 'strange' behaviour I am seeing is when I am attempting to either copy or rename files from this directory down to a subdirectory
>
>The files throwing an error are indeed open for write access BUT they fall outside the creation date time for the file selection command, so they should not be in the attempted copy/rename selection set

Stupid question:  What error do you get?

Only slightly less stupid question:  Does it happen when you pick one
particular file, something.log, that you know is open for writing but
which was created today and say "COPY/LOG/BEFORE=TODAY
something.log;*"?

Related question:  Is the behavior consistent?  Are the same
open-for-writing-but-created-today files getting the same error every
time?

>
>The command is of the form: copy/log/before=today *.log;* [.old]*.*;*
>The problem is also evidenced using: rename/log/before=today *.log;* [.old]*.*;*
>
>Backup with the /before=today qualifier does not experience the issue or even throw a warning, it correctly excludes the files
>
>Does anyone know if this is a bug or if it's intended behaviour? Seems a bit strange if it's intended behaviour to my way of thinking
>
>For example, Filename1 was definitely created yesterday and is not open for write and it copies down to the subdirectory correctly
>
>Filename2 was definitely created today, not yesterday, but is open for write, yet somehow it is being selected for the copy operation (or at least is causing an error to be thrown)
>
>I have performed an ana/disk/repair in case there was anything strange with the volume but that didn't make any difference when I attempted the copy/before=today command again
>
>So, is this because RMS has to actually open the file header to see what the file creation date is and therefore is throwing the error?
> 
>I have not tested this on an ODS5 volume

Louis