[Info-vax] VMSTAR update candidate?

[Steven Schweda]

John E. Malmberg wrote:

> Have you tested it for handling VMS executable binaries?

   Not until now.  Seems to work, unless the conversion to
Stream_LF bothers you.  If I'm worried about non-UNIX-like
files, I tend to avoid "tar" of any kind.

> This does not work in the existing gnu tar builds because stat() is
> reporting a different size than the 512 block boundary that actually is
> in the file, and this is causing the resulting tar archive to be
> corrupted, since the stat() size value is used instead of the number of
> bytes that are actually read in.

   It's _VMS_TAR.  Not a big user of stat().

> The tar specification now has options that allow adding record types for
> special file structures.  These can be used to store VMS file attributes
> for archiving any type of VMS files.

   I'd tend to use [Un]Zip in any case where VMS file
attributes are important.  To the extent that the Info-ZIP
programs do the right thing, stealing the attribute
store-and-restore method used there might be reasonable.  That
wheel seems to be round enough to reuse.

>   I have not had time to work out
> the details of implementing that.

   I can beat that.  I lack the ambition.

> Please put entries in the PORTING_TO_VMS conference on encompasserve.org
>   about what things that you have learned about porting projects.

   Should be possible.  Of course, this is not really a
_porting_ project.  _GNU_ "tar" is a _porting_ project.

   I thought that I had tested this better, but there seems to
be a bug in the >8GB file size storage when creating an
archive.  I'll see if I can straighten that out for "-pre7".
Extracting seems to be ok.   I left some noise in
DESCRIP_SRC.MMS, too:

### LINKFLAGS_DBG = /notraceback
LINKFLAGS_DBG = /traceback

Sigh.  Trust no one, especially me, I always say.  More ODS5
exercise would probably be wise, too.