topic Re: Possible V8.2 $ BACKUP /INPUT_FILES bug in Operating System - OpenVMS

Possible V8.2 $ BACKUP /INPUT_FILES bug

WWarren — Wed, 07 Feb 2007 17:34:24 GMT

The file BACKUP.DAT contains the following 2 lines (both files exist):

DISK$USR00:[WAYNEW]bug.doc;1
DISK$USR00:[WAYNEW].rnd;1

$ BACKUP BACKUP.DAT/INPUT_FILES W.BCK/SAVE
%BACKUP-W-NOFILES, no files selected from DISK$USR00:[WAYNEW]bug.rnd;1

If I change BACKUP.DAT so that .rnd is first, no error is produced.

It is interesting to note that this behavior does not occur if I supply a filespec with a null file type.

Can anyone suggest a work-around other than reordering file specs? Does this behavior replicate in V8.3?

Environment:
AlphaVMS V8.2, with VMS82A_BACKUP-V0100 applied

image name: "BACKUP"
image file identification: "V8.2"
image file build identification: "XAJT-0070050003"
link date/time: 13-JUL-2005 14:56:06.65
linker identification: "A11-50"

image name: "BACKUPSHR"
image file identification: "V8.2"
image file build identification: "XAJT-0070050003"
link date/time: 13-JUL-2005 14:55:12.66
linker identification: "A11-50"

Re: Possible V8.2 $ BACKUP /INPUT_FILES bug

Hoff — Wed, 07 Feb 2007 17:53:02 GMT

This is intended and documented behavior of BACKUP /INPUT_FILES. From the manuals:

"If the disk, directory, or file extension is not specified, the defaults are copied from the previous entry or from the default if this is the first entry."

That text is from the current BACKUP documentation.

The Linker maintainer finally added a knob to optionally turn some similar filename stickiness processing over there off. See RMS_RELATED_CONTEXT=NO" in the linker manual. Stickiness is obscure and useful and long-standing behavior of OpenVMS, and omitted fields will default.

You might be able to bypass this by quoting the string, but I have not checked to see if BACKUP /INPUT_FILES supports this particular escape hatch. I usually avoid null names, as seemingly weird stuff can ensue -- at least until you find out what happened with the defaulting and the stickiness.

Straight DCL commands can and do display this stickiness and field defaulting, too.

Stephen Hoffman
HoffmanLabs

Re: Possible V8.2 $ BACKUP /INPUT_FILES bug

Hoff — Wed, 07 Feb 2007 17:55:16 GMT

Neglected to cite the URL for the cited BACKUP /INPUT_FILES text:

http://h71000.www7.hp.com/doc/83final/6048/6048pro_023.html

Re: Possible V8.2 $ BACKUP /INPUT_FILES bug

WWarren — Wed, 07 Feb 2007 18:16:57 GMT

Oops - right you are - the description was right there in the Example section (rather than the Description section). Shame on me!

Setting the file spec (or the file name section) in quotes produces an error, so no luck there.

And as I mentioned, a null file type doesn't produce the behavior, which I suppose it should according to the documentation (perhaps the meaning of "file extension" is ambiguous?).

To me, this is very, very ugly...

Re: Possible V8.2 $ BACKUP /INPUT_FILES bug

WWarren — Wed, 07 Feb 2007 19:05:26 GMT

Since I'm building backup save sets from command procedure, human inspection is unworkable. As in this example, ported software often creates these null filename beasties; renaming the files is not a solution.

I guess I'll just have to check for null file names as I'm scanning directories and place them at the beginning of the file, even if they're out of directory tree order.

Thanks for the prompt replies!

Re: Possible V8.2 $ BACKUP /INPUT_FILES bug

Hein van den Heuvel — Thu, 08 Feb 2007 00:10:00 GMT

Only ugly workaround is to pass a nodename in front of those nameless files.
With proxies enabled: 0::.rnd
Or 0"user pass"::.rnd
Yuck!

Hein

Re: Possible V8.2 $ BACKUP /INPUT_FILES bug

EdgarZamora — Fri, 09 Feb 2007 12:09:40 GMT

I haven't thought this through and I'm getting yelled by people waiting to go to lunch with me, but what about sorting your input file, BACKUP.DAT, first?

SOURCE> type a.a
DISK$USR00:[WAYNEW]bug.doc;1
DISK$USR00:[WAYNEW].rnd;1
SOURCE> sort a.a
_Output: a.b
SOURCE> type a.b
DISK$USR00:[WAYNEW].rnd;1
DISK$USR00:[WAYNEW]bug.doc;1
SOURCE>

Re: Possible V8.2 $ BACKUP /INPUT_FILES bug

Jess Goodman — Fri, 09 Feb 2007 18:39:59 GMT

The reason this is not a problem with file types is that the specification "name."
explicitly specifies a null file type, as opposed to "name" where the file type is missing.

Unfortunately there no way to explicitly specify a null file name with DCL, so you have this type of problem when either sticky names or wildcard defaults are involved.

So although you can do "CREATE .TXT", if you then do "DIRECTORY .TXT" you actually get a directory of *.TXT;*

Re: Possible V8.2 $ BACKUP /INPUT_FILES bug

WWarren — Tue, 13 Feb 2007 20:16:35 GMT

Hein - nice thought; I hadn't considered that idea.

Edgar - I don't think that sorting the file won't work without a lot of effort because I think I'd need to transform each record so the position of the file name was in a fixed column, sort, and convert back.

Jess - nice explanation! It makes sense.

Thanks again to all who replied!