[Info-vax] VMS - The new file system. What do we know about it?...

[Steven Schweda]

> IIRC zipfiles contain an index at the end of file, and if you can't read
> that the whole thing is toast.

   Define "toast".  Here's an example of some intentional damage to that
"index at the end of file", whose official title is "central directory":

alp $ dire /size unz600dn.zip
[...]
unz600dn.zip;1           588

alp $ unzipx -t unz600dn.zip
Archive:  ALP$DKC0:[SMS.IZ]unz600dn.zip;1
[...]
    testing: README                   OK
[...]
    testing: VBunzip.exe              OK
    testing: CSharpInfoZip_UnZipSample.exe   OK
No errors detected in compressed data of ALP$DKC0:[SMS.IZ]unz600dn.zip;1.

alp $ back unz600dn.zip unz600dn_trunc.zip
alp $ set file /att = efb = 582 unz600dn_trunc.zip

   That eliminates the whole central directory (and part of the last
file).  And it's true that UnZip now hates the thing:

alp $ unzipx -t  unz600dn_trunc.zip
Archive:  ALP$DKC0:[SMS.IZ]unz600dn_trunc.zip;1
  End-of-central-directory signature not found.  Either this file is not
  a zipfile, or it constitutes one disk of a multi-part archive.  In the
  latter case the central directory and zipfile comment will be found on
  the last disk(s) of this archive.
Archive:  ALP$DKC0:[SMS.IZ]unz600dn_trunc.zip;1
  End-of-central-directory signature not found.  Either this file is not
  a zipfile, or it constitutes one disk of a multi-part archive.  In the
  latter case the central directory and zipfile comment will be found on
  the last disk(s) of this archive.

   But Zip has some "fix" options, and one of them is willing to try to
reconstruct the central directory from the local file data headers:

alp $ zip3l -FF --out unz600dn_trunc_ff.zip unz600dn_trunc.zip
Fix archive (-FF) - salvage what can
        zip warning: Missing end (EOCDR) signature - either this archive
                     is not readable or the end is damaged
Is this a single-disk archive?  (y/n): y
  Assuming single-disk archive
Scanning for entries...
 copying: README  (7821 bytes)
[...]
 copying: VBunzip.exe  (12969 bytes)
 copying: CSharpInfoZip_UnZipSample.exe  (13286 bytes)

   Now:

alp $ unzipx -t unz600dn_trunc_ff.zip
Archive:  ALP$DKC0:[SMS.IZ]unz600dn_trunc_ff.zip;1
    testing: README                   OK
[...]
    testing: VBunzip.exe              OK
    testing: CSharpInfoZip_UnZipSample.exe  ERROR:  invalid compressed data to i
nflate
At least one error was detected in ALP$DKC0:[SMS.IZ]unz600dn_trunc_ff.zip;1.

   So, the discarded data from the last archive member was lost, and
could not be recovered, but the damage to the central directory itself
can be worked around.

   This is not proof that Zip+UnZip beats BACKUP in all situations, but
some apparent weaknesses may be more apparent than real.