Here the bitmaps are written as
CLRI or BITS with c_count <= 512
ADDR* for the remaining blocks
Remove the bitmap handling from getfile(), remove xtrmap() and xtrmapskip().
Add new function getbitmap() modeled after getfile() that does bitmap
allocation, bitmap expansion and sets maxino.
Reviewed by: Manuel Bouyer <bouyer@netbsd.org>
through sort before being feed to mtree) with file flags, instead of restoring
file flags at the same time as other attributes. Fix various issue with
schg, uchg, sappnd or uappnd flags which cause restore to fail in some case.
Discussed on tech-userlevel:
http://mail-index.netbsd.org/tech-userlevel/2004/10/12/0000.html
64 bit block pointers, extended attribute storage, and a few
other things.
This commit does not yet include the code to manipulate the extended
storage (for e.g. ACLs), this will be done later.
Originally written by Kirk McKusick and Network Associates Laboratories for
FreeBSD.
In particular, this means that if one member (say the last member) of a tape
set begins with continuation blocks, restore will not consider that tape
to contain all the inodes (curfile.ino==0 at the beginning of the tape).
Close PR #15545.
from stephen.ma@jtec.com.au:
- call getfile() before altering file attributes.
- open file with mode 0600 instead of 0666 so that file won't remain
group or world readable/writable even if getfile() terminated.
- also, move skipfile() before altering file attributes in IF{CHR,BLK} and
IFIFO case for symmetry (suggested by Charles M. Hannum).
writing data to the file system, if the "optimal" file system I/O
operation block size is less than TP_BSIZE, leave fssize alone (i.e.
at its default setting of MAXBSIZE). This was causing restore's
stack to be trashed, because the end-of-buffer checking/flushing code
around line 680 would never notice that the buffer was full (because
it'd be comparing a buffer segment index, which would always be >= 1, to
fssize / TP_BSIZE, which could be zero in that case), and would keep
filling and filling and filling...
