Re: amrecover hard codes restore arguments that fail

Peter Collinson <[email protected]> Sat, 24 Jan 2026 18:11:21 +0000
Newsgroups gmane.comp.archivers.amanda.devel
Message-ID <[email protected]>
The problem is that the arguments for restore are hard coded in the Amanda recover/extract_list.c code, and should be configurable.

The POSIX syntax for restore is not new, what’s new is that it’s complaining about specifying a block size of 2. The error message isn’t that helpful, to be true. The POSIX syntax is shown in the manual page and is undoubtedly supported everywhere and has been for eons. 

I don’t remember a time when I had to give the block size to restore, I was using DAT tapes maybe 20+ years ago, but since then I store stuff on disks. Do people still use tapes with a fixed block size?

I found that the Debian contact for dump/restore is very responsive and can be probably answer your questions about portability. He can be found at ‘az’ at ‘debian.org’.

I suspect that many Amanda users have tar as their storage media, but I prefer dump/restore that has a really well developed changes system which massively saves disk space.

Sorry, I am not at all responsible for dump/restore. I just happen to be a user who was hit when upgrading to Debian 13.

What I have installed at present is a shell script for restore:

#!/bin/sh
# fix problems with amrecover and the restore program
# on trixie.
# To make this work move
# /sbin/restore to /sbin/real/restore
# and install this as /sbin/restore
#
# This checks that first arguments that are
# xbf 2 -
# and replaces them with -x -f -
if [ "${1}${2}${3}" = 'xbf2-' ]; then
    # remove xbf 2 from the arguments
    # leaving the -
    shift; shift
    # call restore with
    exec /sbin/real/restore -x -f $@
else
    exec /sbin/real/restore $@
fi

Which may help people who find that you can check things in with Amanda, but find Hotel California rules apply.

Regards
--------------------------------------------------
Peter Collinson



> On 24 Jan 2026, at 17:09, Dustin J. Mitchell <[email protected]> wrote:
> 
> I haven't thought about this since the aughts, but a few things come up:
>  - Can you narrow down the change to a particular diff in `restore`? It would be good to know that the new syntax matches the old.
>  - I suspect that getting block size wrong in the restore would lead to weird errors. Already the comment and value in extract_list.c do not match ("2" and "read in units of 1K")! Knowing more about how this works would be good. How does "tries to determine the media block size dynamically" work? How reliable is it?
>  - Would the updated syntax work for older restores, and all flavors (BSD and GNU/Linux)?
> 
> Aside from that, I don't have any way to land a fix or even know who to talk to at this point!
> 
> Dustin
> 
> On Sat, Jan 24, 2026 at 1:38 AM Peter Collinson <[email protected]> wrote:
> I am a very long time Amanda user. My Amanda server runs on Debian system and I've recently upgraded to trixie.
> My Amanda system entirely disk based, using the magic virtual tape changer. Things appeared to work, dumps are happening, but a big problem arose when I tried to use amrecover to retrieve a file.
> 
> Amrecover extracts the dump image from the stored file, unzips them to get the dump image and calls restore like:
> 
> cat file | restore xbf 2 - files/to/extract
> 
> Restore on trixie immediately says:
> 
> restore: Tape blocksize is too large, use '-b 10’
> 
> and gives up. This is not a very helpful error message, and has only appeared on this release of Debian. It seems that restore is very unhappy with the 2 here. This isn’t really following the man page for restore, but this would
> 
> cat file | restore -x -b 2 -f - files/to/extract
> 
> and it also fails. Replacing the 2 with 10 make things work.
> 
> The xbf coding has been in amanda since the dawn of time, so this looks like it will break all Amanda installations across the planet that still use dump/restore. Why can’t it just ignore the block size and let it work out what to use? If does that when no block size is given:
> 
> cat file | restore xf - files/to/extract
> 
> or better
> 
> cat file | restore -x -f - files/to/extract
> 
> just works. 
> 
> The code in recover-src/extract_list.c hardcodes this - (line 1756 in Debian source)
> 
> g_ptr_array_add(argv_ptr, g_strdup("xbf"));
> g_ptr_array_add(argv_ptr, g_strdup("2")); /* read in units of 1K */
> g_ptr_array_add(argv_ptr, g_strdup("-")); /* data on stdin */
> 
> this really ought to be changed to
> 
> g_ptr_array_add(argv_ptr, g_strdup("-x"));
> g_ptr_array_add(argv_ptr, g_strdup("-f")); /* read in units of 1K */
> g_ptr_array_add(argv_ptr, g_strdup("-")); /* data on stdin */
> 
> which moves things onto using the manual page for restore.
> 
> As a temporary work around, I've replaced my /usr/sbin/restore by a shell script that generates the 'right' arguments when it finds xbf 2 -.
> 
> 
> Regards
> --------------------------------------------------
> Peter Collinson
> 
>