> From: "Main, Kerry"
>
> > Just a WAG, but since you are doing mostly write activities, can we assume
> > That you have removed disk highwater marking and set OpenVMS to the file
> > system default That UNIX uses (write back) vs OpenVMS's file system default
> > (write through)?

>
> I didn't. I didn't realize how doomed I was until I stepped well
> into this tar-pit.
>
> Volume Status: ODS-5, subject to mount verification, protected subsystems
> enabled, file high-water marking, write-through caching enabled, hard
> links enabled.
>
> When I get a chance, I'll try to look into VMSTAR to see if it is (or
> could be) using SQO to help avoid highwater marking trouble. In the
> past, it only bothered me when allocating space for a big file, and I
> believe that the files themselves are all pretty small. Should I still
> worry?


For the record, even before I started fiddling with it (V3.4-1),
VMSTAR was pre-allocating disk space for extracted files
("fil_fab.fab$l_alq = (unsigned long) ((bytes+511)/512);"), and the
edition which I've been using (V3.5-pre2,
"http://antinode.org/ftp/vmstar/v3r5_pre2_src.zip") also sets the
"sequential access only" flag ("fil_fab.fab$l_fop |= FAB$M_SQO;"), so,
pending a good counter-argument, I'll believe that highwater marking
shouldn't be bothering the application code. (If it's hampering the OS
and/or file system, then I figure that I can pass along the blame for
that to someone else.)

Lacking an override from the user, it should also (now) be using 127
for the multi-block count ("fil_rab.rab$b_mbc"), and using two buffers
("fil_rab.rab$b_mbf"), and setting write-behind ("fil_rab.rab$l_rop |=
RAB$M_WBH;") on the extracted files. (This code now looks remarkably
like the corresponding code in UnZip. A coincidence, no doubt.)

I'll admit that extracting an archive using VMSTAR has always seemed
much slower than using any real "tar" on a UNIX system, which is one
reason I started adding this code to it in the first place. I'll also
admit that my changes probably didn't make a world of difference in that
situation. (I will claim that it handles symlinks and GNU "tar" long
names better than it did, though.)

------------------------------------------------------------------------

Steven M. Schweda sms@antinode-org
382 South Warwick Street (+1) 651-699-9818
Saint Paul MN 55105-2547