Re: Questions about selective restore, slice handling and -E behavior with and catalog-file

Hi Denis,

as discussed, here are the results of my tests with different -E parameters.

== -E "cp .... " ==
touch temp/1234-2025_2025-08-14T07.16.50_.204.dar

dar -A 1234-2025_2025-08-14T07.16.50_CAT
-x temp/1234-2025_2025-08-14T07.16.50_
-R /media/raid10/restore
-g "1234-2025/25-0585/test.pdf"
-w
-K "$(cat 1234-2025_2025-08-14T07.16.50_password.txt)"
-E "cp /media/ltfs/%b.%N.%e %p"

Warning, the archive 0999316-2025_2025-08-14T07.16.50_ has been
encrypted. A wrong key is not possible to detect, it would cause DAR
to report the archive as corrupted


 --------------------------------------------
 7 inode(s) restored
    including 0 hard link(s)
 0 inode(s) not restored (not saved in archive)
 0 inode(s) not restored (overwriting policy decision)
 40 inode(s) ignored (excluded by filters)
 0 inode(s) failed to restore (filesystem error)
 0 inode(s) deleted
 --------------------------------------------
 Total number of inode(s) considered: 47
 --------------------------------------------
 EA restored for 0 inode(s)
 FSA restored for 0 inode(s)
 --------------------------------------------

dar works because it detects the name structure by the created "dummy"
last slice an copies it again. Better than copying it first manual and
than by dar again.

== -E "cp -n ...." ==

touch temp/1234-2025_2025-08-14T07.16.50_.204.dar

dar -A 1234-2025_2025-08-14T07.16.50_CAT
-x temp/1234-2025_2025-08-14T07.16.50_
-R /media/raid10/restore
-g "1234-2025/25-0585/test.pdf"
-w
-K "$(cat 1234-2025_2025-08-14T07.16.50_password.txt)"
-E "cp -n /media/ltfs/%b.%N.%e %p"

234-2025_2025-08-14T07.16.50_.204.dar has a bad or corrupted header,
please provide the correct file. [return = YES | Esc = NO]
Escaping...
Final memory cleanup...
Aborting program. User refused to continue while asking:
234-2025_2025-08-14T07.16.50_.204.dar has a bad or corrupted header,
please provide the correct file.

My interpretation: DAR attempts to copy the last slice again.
Normally, cp would overwrite the existing file, but due to the -n
parameter, overwriting is prevented. As a result, the restore fails,
if using a dummy file. Would work as aspected using the original last
slice.

== -E "echo cp ...." ==

touch temp/1234-2025_2025-08-14T07.16.50_.204.dar

dar -A 1234-2025_2025-08-14T07.16.50_CAT
-x temp/1234-2025_2025-08-14T07.16.50_
-R /media/raid10/restore
-g "1234-2025/25-0585/test.pdf"
-w
-K "$(cat 1234-2025_2025-08-14T07.16.50_password.txt)"
-E "echo cp /media/ltfs/%b.%N.%e %p"

cp /media/ltfs/1234-2025_2025-08-14T07.16.50_.204.dar /home/user01/temp/
234-2025_2025-08-14T07.16.50_.204.dar has a bad or corrupted header,
please provide the correct file. [return = YES | Esc = NO]
Escaping...
Final memory cleanup...
Aborting program. User refused to continue while asking:
234-2025_2025-08-14T07.16.50_.204.dar has a bad or corrupted header,
please provide the correct file.

Here you can see that DAR triggers cp to copy the last slice again,
even though it is already present. This confirms my assumption.

Workarounds:
As you already suggested, either use cp -n to avoid overwriting
existing files, or keep the first slice very small using -S 1k.

Cheers,

Ralf

Am Do., 16. Apr. 2026 um 21:03 Uhr schrieb Denis Corbin via
Dar-support <[email protected]>:
>
>
> [...]
>
> >> == My questions ==
> >>
> >> Why are the required slices not automatically copied using the -E
> >> option? It seems that the slice numbering is not handled with three
> >> digits, even though .%N. is used.
> >
> > if having a doubt on the command you pass to dar, I would suggest using
> > dar's --empty option (dry-run) and prepend the command passed to -E by
> > an echo:
> >      dar
> >      [...]
> >      --empty
> >      -E "echo cp -n /media/ltfs/%b.%N.%e %p"
> >
>
>
> > this will show the command that should be executed without doing
> > anything, so you can quickly check and tune.
> Sorry this will not work unless you have slices available, even if
> nothing is restored nor modified, dar still needs to read the slice.
> You can however check with a small faking backup of many slices
> (smallest slice possible is a few hundred bytes...).
>
>