Conference vaxaxp::vmsnotes

    It is certainly possible to use /truncate on both write and read to
    avoid writing extra stuff. Backup accepts this on /image mode
    copies, though I can't say with certainty that nothing extra gets
    on the tape. Certainly when restoring a tape made with /trunc
    to a disk with cluster factor 1, the extra blocks are not there.
    Extra stuff in the last block is less clear. One of the backup
    designers/maintainers will need to reply on that.
    

   With highwater marking enabled on the source file(s) or source volume(s),
   the answer to the question should be obvious -- there is no "scavenging"
   permissible without correspondingly powerful user privileges...

   As a general rule, if the customer has the access for image mode or
   standalone operations, then by definition, the user has full-privileged
   volume access -- the entire volume can be read.

   If the target system has file highwater marking, only privileged users
   there can see any data between the EOF and the end of allocated space.

   The overhead of highwater marking is very minor, save for the case when
   an access is regularly performed well beyond the current end of file,
   when the endof-file has to be moved out by a large value, and erasure
   of the intervening space must occur.  Or when there is file-level
   sharing going on, when the XQP switches over to a more conservative
   erase-on-allocate scheme.
   
   As an option here, keep one volume around with highwater marking
   and erase-on-delete, etc, enabled, and COPY files to this area for
   staging for later transference to the remote (less-trusted) system.

   And, to answer your question, BACKUP honors the highwater marking
   setting on the file or volume -- if highwater marking is not enabled,
   then I would not expect BACKUP to enforce it...

Two great answers in exactly two hours - I love notes.

Thank you both for your input - I'll pass it along to the customer this
afternoon. Steve, the idea of keeping a spare volume around with highwater 
marking enabled (and initted with a cluster size of 1) is great! I wish I'd 
have thought of that.

Thanks again,
tim moffitt

re .0
    
>Let's say I'm moving a file with a length of 1436 bytes from a disk with a 
>cluster size of 4 blocks. I want to be sure that only the 1436 bytes in the 
>file are actually being put to tape during the image backup - not the
>additional 100 bytes that it would take to pad the third block in the 
>cluster and, certainly none of the 4th block in the cluster.
    
    At a quick look with BACK/ANA it would seem that BACKUP always saves
    complete 512 byte blocks but does not save beyond the block containing
    EOF. [BACKUP will store on the saveset the ALQ and by default when
    restoring the file will allocate this amount but any scavenging caused by
    this occurs on the target system.]
    
    I have never seen data to scavenge beyond EOF in the last block but if
    it's there I wouldn't be confident that it is not being saved unless
    Mr BACKUP says otherwise. You could test it out for yourself of course.
    
P.S. It is near impossible to find a disk to initialise with cluster size 1
these days. Disks are too big for this.

  re .0: If the customer is parinoid enough about extra bits left around the
  place to worry about backups, perhaps he should consider setting the 
  volume to ERASE-ON-DELETE ($ SET VOLUME/ERASE_ON_DELETE disk). That way
  they won't have stray information left on the disk at all.

						John Gillings, Sydney CSC