Possible V8.2 $ BACKUP /INPUT_FILES bug

[WWarren]

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"

[Hoff · Accepted solution]

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

[Hoff]

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

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

[WWarren]

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

[WWarren]

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!

[Hein van den Heuvel]

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

[EdgarZamora]

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>

[Jess Goodman]

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

[WWarren]

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!