tar in multi-volume mode relies on a
ENOSPC error to detect the end of the first tape and prompt the user for the next tape.
To simulate this behaviour consider the following example by writing to
tar -cvf - --multi-volume . > /dev/full
as expected results in
[...] Prepare volume #2 for ‘-’ and hit return:
A problem arises when piping the output of
tar through an encyption program like
tar -cvf - --multi-volume . | gpg -c --batch -q --passphrase 123 > /dev/full
gpg to exit with code 2
gpg: [stdout]: write error: No space left on device gpg: [stdout]: write error: No space left on device gpg: filter_flush failed on close: No space left on device
The ENOSPC is obviously not propagated to tar, which isn't made aware of the specific errno. Is there a way to catch the error from
gpg and "re-raise" the ENOSPC error to
tar with a bash script?
For example, using tar with a named pipe results in a broken pipe once
gpg fails and tar subsequently exists with SIGPIPE 141 -- however
ENOSPC still has to be signaled to tar in some way instead of the broken pipe error.
I would like to avoid the workaround of specifying a fixed tape size.
I am also aware of using
mbuffer to handle tape spanning, which is undesireable because tapes can not be extracted individually.
EDIT: I just realized this is going to be a lot more complicated, as the data that has already left tar and was in the buffer when ENOSPC was encountered is most likely lost. Though most tape driver implementations allow another write operation after that, gpg and aespipe include no retry logic to save the data in the buffer.
EDIT 2: Further research shows that
star on FreeBSD with the
-compress-program option to perform the encryption in conjunction with
new-volume-script=... raises the error
star: Operation not permitted. Cannot lock fifo memory. star: Can only compress files
when writing to a device instead of a file. So that's a dead end too.