Amanda-Users

Re: Append Files using tar

2005-04-12 10:24:21
Subject: Re: Append Files using tar
From: Paul Bijnens <paul.bijnens AT xplanation DOT com>
To: kshriyan AT redhat DOT com
Date: Tue, 12 Apr 2005 16:15:51 +0200
Kaushal Shriyan wrote:
[...]
[root@spica tartest]# mt -f /dev/nst0 rewind
[root@spica tartest]# tar -tvf /dev/nst0
drwxr-xr-x root/root         0 2005-04-01 15:54:53 folderA/
-rw-r--r-- root/root         7 2005-04-01 15:54:48 folderA/t1
-rw-r--r-- root/root        10 2005-04-01 15:54:55 folderA/t2
[root@spica tartest]# mt -f /dev/nst0 rewind
[root@spica tartest]# tar -rvf /dev/nst0 folderB
folderB/
folderB/t3
folderB/t4
[root@spica tartest]# mt -f /dev/nst0 rewind
[root@spica tartest]# tar -tvf /dev/nst0
drwxr-xr-x root/root         0 2005-04-01 15:54:53 folderA/
-rw-r--r-- root/root         7 2005-04-01 15:54:48 folderA/t1
-rw-r--r-- root/root        10 2005-04-01 15:54:55 folderA/t2
[root@spica tartest]#


As you can see, in the end when i do tar -tvf /dev/nst0, only the contents
of folder A
are displayed and that of folderB are not displayed. This does not meet our
requirement.
We want the contents of both the folders.

This has actually nothing to do with amanda.
What you're trying to do is to use tar to append to an existing
archive.

This works when the archive is on a disk, but it does not work on
most tapedrives.  (Actually, I do not know any modern tape drive where
it does work!  I did use 9-inch reels, but that was on an IBM mainframe
running MVS; and I guess it can be done on such devices -- but never
tried myself.  I do not have access anymore to such tapedrives either.)

A tapedevice has no "inode" to indicate the size of a file to know
where it ends.  Instead it writes a marker after a file to signal
the end of file.  When reading a tapefile, and the program reads
this marker, it returns 0 from the next read(), the common way to
indicate EOF in programs.

When tar has to update an archive on disk, it can read to the end of
the file, keep the last block in memory, overwrite the trailer
in that block with the file-announcement and bytes of the next file,
and overwrite that block again.

When tar has to update a tape, it would have to read to the end
of the file (by reading up to and including that marker), *rewind*
*a* *little*, and rewrite that updated last block.

Most modern tapedevices are not random access.
I don't know how to "rewind a little", and neither does the gnutar
programmer which states in the beginning of the "update.c" source
file: "... if [the files] are on raw tape or something like that,
it will probably lose... */ ".

I guess that if you "dd" the first file, you find a nice tar file,
and if you "dd" the next file, which seems to be written to
tape too, you'll find another file beginning with the last block
again, now having the trailer replaced with the next archive members.
Useless actually.



--
Paul Bijnens, Xplanation                            Tel  +32 16 397.511
Technologielaan 21 bus 2, B-3001 Leuven, BELGIUM    Fax  +32 16 397.512
http://www.xplanation.com/          email:  Paul.Bijnens AT xplanation DOT com
***********************************************************************
* I think I've got the hang of it now:  exit, ^D, ^C, ^\, ^Z, ^Q, F6, *
* quit,  ZZ, :q, :q!,  M-Z, ^X^C,  logoff, logout, close, bye,  /bye, *
* stop, end, F3, ~., ^]c, +++ ATH, disconnect, halt,  abort,  hangup, *
* PF4, F20, ^X^X, :D::D, KJOB, F14-f-e, F8-e,  kill -1 $$,  shutdown, *
* kill -9 1,  Alt-F4,  Ctrl-Alt-Del,  AltGr-NumLock,  Stop-A,  ...    *
* ...  "Are you sure?"  ...   YES   ...   Phew ...   I'm out          *
***********************************************************************



<Prev in Thread] Current Thread [Next in Thread>