[Info-vax] OpenVMS - file selection abnormally with Copy / Rename or user ignorance?
mcleanjoh at gmail.com
mcleanjoh at gmail.com
Tue Mar 31 17:48:33 EDT 2015
On Tuesday, March 31, 2015 at 11:27:48 PM UTC+11, Bob Gezelter wrote:
> On Monday, March 30, 2015 at 5:18:50 PM UTC-4, mcle... at gmail.com wrote:
> > On Monday, March 30, 2015 at 8:22:10 PM UTC+11, hb wrote:
> > > On 03/30/2015 06:31 AM, mcleanjdh at xmail.com wrote:
> > > > Yes, the dates are stored in the header block (i.e. in INDEXF.SYS)
> > > and a file that's open for write is likely to modify the data, so
> > > I'm not surprised that COPY/SINCE= and RENAME/SINCE= object and
> > > that omitting the /SINCE works fine.
> > >
> > > Doesn't make sense to me, but what do I know. Do you expect
> > > dir/date/since= to work for files that are open for writing?
> > >
> > > > A question for IanD, are you sure they are errors?
> > > >
> > > > I think you are more likely to get %W messages (i.e. warnings),
> > > rather than "%E" (error), at least that's the way I would have
> > > written COPY and RENAME.
> > >
> > > He didn't show them but it is easy to reproduce (OpenVMS/I64 V8.4):
> > > $ cre/dir [.saved]
> > > $ open/write out x.tmp
> > > $ write out "hello
> > > $
> > > $ copy /before=today *.tmp [.saved]
> > > %COPY-E-OPENIN, error opening DISK$USER:[USER]x.tmp;1 as input
> > > -RMS-E-FLK, file currently locked by another user
> > > $
> > > $ backup /before=today *.tmp [.saved]
> > > %BACKUP-E-OPENIN, error opening DISK$USER:[USER]x.tmp;1 as input
> > > -SYSTEM-W-ACCONFLICT, file access conflict
> > > $
> > > $ delete [.saved]*.*;*
> > > $ backup /ignore=inter/before=today *.tmp [.saved]
> > > $ dir/date=all/since *.tmp
> > >
> > > Directory DISK$USER:[USER]
> > >
> > > x.tmp;1 30-MAR-2015 10:59:36.78 30-MAR-2015 10:59:36.78
> > > <None specified> <No backup recorded> <None specified> <None
> > > specified> 30-MAR-20
> > > 15 10:59:36.78 30-MAR-2015 10:59:36.78 30-MAR-2015 10:59:36.78
> > >
> > > Total of 1 file.
> > > $
> > > $ close out
> >
> > So you think there's no difference between copying (or whatever) the data within a file and simply reporting what's in the header block?
> >
> > RENAME would work most of the time but I believe there's a file type that has the file name in the first record of the file, which means that needs to be modified during a rename.
>
> For Files-11 (all versions to date) there is no meta data within the allocated data blocks. To paraphrase a commercial from way back when: Data blocks are data blocks.
>
> There could be user applications that put a copy of what they think the filename is in the first record. That would be a poor design and would not be managed by RMS.
>
> The thought of meta data within data blocks may represent a misremembering/misunderstanding of the role of RMS. RMS does have some filetypes (e.g., indexed) that store some metadata (e.g., key and index information) within what Files-11 considers "data" blocks.
>
> - Bob Gezelter, http://www.rlgsc.com
Bob,
I was told a long time ago that the fudged callable copy, which uses a sequence three calls to CONV$ routines, worked on almost all file types, but fails on the file type that stored its own name in the first block. This information came from a Digital/Compaq/HP employee.
John
More information about the Info-vax
mailing list