dar-support — Any questions or problem using dar, this mailing-list is for you !

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

[Denis C. <dar...@fr...>]

Le 21/04/2026 à 14:09, Moll, Ralf a écrit :
> Hi Denis,

Hi Ralf,

thank you for this feedback,

[...]

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

Note the slightly shift of interpretation you do: I would not say:
"DAR triggers cp to copy the last slice again, even though it is already 
present":

But rather that Dar reads again the last slice (something which is known 
and expected). As such Dar invokes the -E provided command(s) with the 
slice number which will very shortly be need. Dar does not know about 
slice existence when it comes to run a -E command, precisely because it 
occurs *before* this time, for user to do what's necessary for the slice 
to be present in the expected directory (originally by loading a CD or 
DVD in a tray, but in fact anything you want or need like downloading or 
here copying the needed slice).

It is thus, as you have seen, the -E command that should avoid to do 
anything unnecessary when the last slice is to be open again (for 
example using the %c context parameter provided by dar), like avoiding 
to download/copying it again if it has already been downloaded/copied.

The use of -affs does not change this paradigm, but when an isolated 
catalog is provided, it avoids reading twice the same slice (and thus 
invoking the -E provided command(s) twice for the same slice number).


> 
> 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,
> 

Cheers,
Denis

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

[Moll, R. <me...@rm...>]

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 <dar...@li...>:
>
>
> [...]
>
> >> == 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...).
>
>

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

[Denis C. <dar...@fr...>]

Le 16/04/2026 à 22:08, Moll, Ralf a écrit :
> Hi Denis,
> 
> thank you very much for your quick and detailed reply — it really
> helped me a lot.
> 
> You mentioned that metadata is always present in both the first and
> the last slice, and that during restore DAR will, by default, use the
> last slice for metadata access.
> 
> My question is:
> should I already use the parameter during archive creation, for example:
> 
> # Create DAR archive optimized for LTFS tape usage
> dar -c backup \
>    -R /data \                 # Root directory to archive
>    -s 50G \                  # Size of regular slices (data slices)
>    -S 1k \                   # Size of the first slice (metadata anchor)
>    -@ catalog \              # Store isolated catalog
>    --alter=force-first-slice # Force DAR to use metadata from first slice
> 
> or is --alter=force-first-slice only intended to be used during restore?

this is only to be used (as an option) when reading an archive, thus 
when restoring, testing, diffing, listing... an archive.

> 
> Your explanations regarding copying the slices make perfect sense to
> me. Unfortunately, I will only be able to test this again on my system
> next week. I plan to adapt my script and also evaluate the behavior of
> cp, cp -n, and cp --update=all / cp --update=older in combination with
> the placeholder file.
> 
> As expected, extraction did not work using only the placeholder file
> and the catalog. However, I assume that DAR may have used the
> placeholder file to infer information such as the number of slices and
> the numbering scheme, then fetched the last slice and subsequently the
> required slice. That’s just a hypothesis for now — I will verify this
> next week.

this should be checked... but if you generate a placeholder file to 
drive dar to auto-detect the min-digit parameters, better directly set 
it as argument to dar, no?

> 
> It’s really impressive to see how much thought has gone into
> parameters like -s and -S, and to better understand their purpose.
> 
> Separately, I was wondering whether it might be worth considering
> having all required metadata available entirely within the catalog
> file. If the archive structure or slice size changes, access could
> still fall back to the first or last slice, but in most real-world
> cases, the archive layout will likely remain unchanged.

the metadata that leads dar to read the first or last slice the archive 
format version, which defines which field are present, options available
in an archive, the archive table of content (files, attributes, data 
location in the archive are loaded from the isolated catalog). This is 
under consideration to store this information withing an isolated 
catalog in the next major release. Still need to check its feasibility...

> 
> Wishing you and all DAR users a great Friday and a good start into the weekend.

Thanks! wishing the same to you too!
> 
> Best regards,
> Ralf
> 

Cheers,
Denis

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

[Moll, R. <me...@rm...>]

Hi Denis,

thank you very much for your quick and detailed reply — it really
helped me a lot.

You mentioned that metadata is always present in both the first and
the last slice, and that during restore DAR will, by default, use the
last slice for metadata access.

My question is:
should I already use the parameter during archive creation, for example:

# Create DAR archive optimized for LTFS tape usage
dar -c backup \
  -R /data \                 # Root directory to archive
  -s 50G \                  # Size of regular slices (data slices)
  -S 1k \                   # Size of the first slice (metadata anchor)
  -@ catalog \              # Store isolated catalog
  --alter=force-first-slice # Force DAR to use metadata from first slice

or is --alter=force-first-slice only intended to be used during restore?

Your explanations regarding copying the slices make perfect sense to
me. Unfortunately, I will only be able to test this again on my system
next week. I plan to adapt my script and also evaluate the behavior of
cp, cp -n, and cp --update=all / cp --update=older in combination with
the placeholder file.

As expected, extraction did not work using only the placeholder file
and the catalog. However, I assume that DAR may have used the
placeholder file to infer information such as the number of slices and
the numbering scheme, then fetched the last slice and subsequently the
required slice. That’s just a hypothesis for now — I will verify this
next week.

It’s really impressive to see how much thought has gone into
parameters like -s and -S, and to better understand their purpose.

Separately, I was wondering whether it might be worth considering
having all required metadata available entirely within the catalog
file. If the archive structure or slice size changes, access could
still fall back to the first or last slice, but in most real-world
cases, the archive layout will likely remain unchanged.

Wishing you and all DAR users a great Friday and a good start into the weekend.

Best regards,
Ralf

Am Do., 16. Apr. 2026 um 18:48 Uhr schrieb Denis Corbin via
Dar-support <dar...@li...>:
>
> Le 16/04/2026 à 15:04, Moll, Ralf a écrit :
> > Hello Denis,
>
> Hello Ralf,
>
> >
> > first of all, I would like to thank you for your excellent tool.
>
> thanks! :)
>
> > I am
> > currently using DAR in an extended proof of concept in our HQ to
> > archive individual cases to LTFS-formatted LTO-8 tapes in a
> > data-protection-compliant way.
> >
> > = DAR Version =
> > dar version 2.7.8 on Debian 12
> >
> > = Backup Creation =
> >
> > BCK_PAR="--min-digits 3 -s 51200M --hash md5 -vt -vm -M"
> > dar ${BCK_PAR} -@ "${BCK_CAT}CAT" -c "${BCK_DST}" -R "${BCK_SRC_DIR}"
> > -g "${BCK_SRC_BASE}" -Kaes:${BCK_PAS}
> >
> > = Created Files =
> >
> > Slices:
> >
> > 1234-2025_2025-08-14T07.16.50_.001.dar
> > 1234-2025_2025-08-14T07.16.50_.001.dar.md5
> > 1234-2025_2025-08-14T07.16.50_.002.dar
> > 1234-2025_2025-08-14T07.16.50_.002.dar.md5
> > ...
> > 1234-2025_2025-08-14T07.16.50_.204.dar
> > 1234-2025_2025-08-14T07.16.50_.204.dar.md5
> >
> > Each slice has a size of 50 GiB.
> >
> > Catalog file:
> >
> > 1234-2025_2025-08-14T07.16.50_CAT
> >
> > Password file:
> >
> > 1234-2025_2025-08-14T07.16.50_password.txt
> >
> > = Selective Restore =
> >
> > == Determining the relevant slice(s) using the catalog file ==
> >
> > dar -l 1234-2025_2025-08-14T07.16.50_CAT -Tslice -g "1234-2025/25-0585/test.pdf"
> >
> > Output:
> >
> > Slice(s)|[Data ][D][ EA  ][FSA][Compr][S]|Permission| Filename
> > --------+--------------------------------+----------+-----------------------------
> >           [InRef][-]       [---][   0%][ ] drwxrwxrwx 1234-2025
> >           [InRef][-]       [---][   3%][ ] drwxrwxrwx 1234-2025/25-0585
> > 166      [InRef][ ]       [-L-][-----][X] -rwxrwxrwx 1234-2025/25-0585/test.pdf
> > -----
> > All displayed files have their data in slice range [166]
> >
> > Based on the catalog, the file appears to be fully stored in slice 166.
> >
> > == Automatic copying of required slices via -E fails ==
> >
> > 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)" \
> >
> >
> > This results in:
> >
> > cp: cannot stat '/media/ltfs/1234-2025_2025-08-14T07.16.50_.0.dar': No
> > such file or directory
> >
> > followed by:
> >
> > Error during user command line execution: execution of [ cp
> > /media/ltfs/1234-2025_2025-08-14T07.16.50_.0.dar
> > /media/raid5/restore/temp ] returned error code: 256
> >
> > If I explicitly add --min-digits 3, I instead get:
> >
> > Error during user command line execution: execution of [ cp
> > /media/ltfs/1234-2025_2025-08-14T07.16.50_.000.dar
> > /media/raid5/restore/temp ] returned error code: 256
>  > > I have read the following note:
> >
> > “Note that dar will initially require slice number zero, meaning the
> > last slice of the backup...”
> >
> > However, I assumed that this behavior would not be required when using
> > a separate catalog file.
>
> it is because you can change the slicing of an archive even after having
> created an isolated catalog. Thus the last slice cannot be known, but no
> worries, you can drive for dar request the first slice (read below).
>
> And yes, the table of content is loaded from the isolated catalogue, but
> there is still the archive format version to read from the
> backup/archive (which may differ from the isolated catalog if different
> version of dar have been used between backup and isolation). This
> information is located both at the beginning of the first slice and a
> the end of the last slice (which is where it is fetched by default).
>
> You should consider using the -affs option (--alter=force-first-slice)
> to fetch this information from the first slice, and use a tiny first
> slice ("-S 1k"(uppercase S) 1 KB is large enough for that). This way,
> you could store on disk only this tiny first slice and the isolated
> catalogue. Then using the -affs option, you will only load from tape the
> big slices requested to restore a particular file or set of files.
>
> Yes, there is room to improve things, this is something under
> consideration for version 2.9.0.
>
> In the meanwhile you can either store the first or the last slice out of
> tape, which ever is the smaller beside the catalog and only use -affs if
> the smaller is the first. For your next backup, you will surely create a
> tiny first slice...
>
> >
> > == Restore with only slice 166 and catalog still fails ==
> >
> > Even if I manually copy the required slice file (slice 166), the
> > restore still only works if the last slice is also present, although
> > the catalog file is provided:
> >
> > 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)"
> >
> > Output:
> >
> > Auto detecting min-digits to be 3
> > The last file of the set is not present ..., please provide it.
> >
> > == Additional observation regarding -E behavior ==
> >
> > I also observed that the command triggered by -E deletes a manually
> > provided last slice and then copies it again.
>
> if you mean the following argument you passed to dar:
>         -E "cp /media/ltfs/%b.%N.%e %p"
>
> well... dar, by itself does not delete slices...
>
> But yes, this is the way the 'cp' unix command works. If you do not want
> this behavior, better using:
>         -E "cp -n /media/ltfs/%b.%N.%e %p"
>
> (-n option of the unix cp command).
>
> >
> > It seems that the last slice is only required as a placeholder. In
> > fact, I can create it using:
> >
> > touch 1234-2025_2025-08-14T07.16.50_.204.dar
>
> this is not what I observe: I get this error message if I "touch" the
> last slice rather than copying it:
> backup.5.dar has a bad or corrupted header, please provide the correct
> file. [return = YES | Esc = NO]
>
> >
> > and the restore proceeds. This means that copying the full last slice
> > from tape could be avoided, saving time and bandwidth depending on
> > slice size.
>
> If so, replacing the -E option with the following script should solve
> your problem:
>         -E "my_script.duc %p %b %N %e %c"
>
>  > cat my_script.duc
> #!/bin/bash
>
> slicepath="/media/ltfs"
> slicename="$2.$3.$4"
> target="$1"
>
> if [ "$5" = "init" ] ; then
>     touch "$target/$slicename"
> else
>     cp -n "$slicepath/$slicename" "$target"
> fi
>  >
>
> But I would be surprise if it was not issuing the warning I had while
> creating the last slice using "touch".
> [note that I have not tested this above script, it may fails upon syntax
> error, this is just here to expose the idea]
>
> >
> > Is this behavior expected or known?
>
> yes, so far.
>
> >
> > == 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.
>
> > Is it mandatory to also specify
> > --min-digits 3, or is this behavior caused by DAR requiring the last
> > slice despite the presence of a catalog file?
>
> today, dar check the location where slices are to be read and determin
> the min-digit automatically. However, if there is no slice at all,
> obviously you need to provide the --min-digits argument for the -E
> option and its %N macro set the proper number of leader zeros...
>
> > Why does DAR require the last slice during extraction even when a
> > separate catalog file is provided with -A?
>
> should now have the answer from answer above, see also man page
> regarding -affs option to get more details.
>
> > This reduces robustness, as
> > the last slice must always be present and intact, even if the
> > requested file resides in a different slice.
>
> the last or the first slice.
>
> > Is the behavior of deleting and re-copying the last slice via -E
> > expected?
>
> -E is doing what the user tells it to run... nothing more, nothing less ;)
>
> > And is it intentional that a zero-length placeholder file is
> > sufficient for the restore process?
>
> it is not and it should unfortunately not work, check with the script I
> provided and let me know.
>
> >
> > Best regards,
> >
> > Ralf
> >
>
> Cheers,
> Denis
>
>
>

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

[Denis C. <dar...@fr...>]

[...]

>> == 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...).

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

[Denis C. <dar...@fr...>]

Le 16/04/2026 à 15:04, Moll, Ralf a écrit :
> Hello Denis,

Hello Ralf,

> 
> first of all, I would like to thank you for your excellent tool. 

thanks! :)

> I am
> currently using DAR in an extended proof of concept in our HQ to
> archive individual cases to LTFS-formatted LTO-8 tapes in a
> data-protection-compliant way.
> 
> = DAR Version =
> dar version 2.7.8 on Debian 12
> 
> = Backup Creation =
> 
> BCK_PAR="--min-digits 3 -s 51200M --hash md5 -vt -vm -M"
> dar ${BCK_PAR} -@ "${BCK_CAT}CAT" -c "${BCK_DST}" -R "${BCK_SRC_DIR}"
> -g "${BCK_SRC_BASE}" -Kaes:${BCK_PAS}
> 
> = Created Files =
> 
> Slices:
> 
> 1234-2025_2025-08-14T07.16.50_.001.dar
> 1234-2025_2025-08-14T07.16.50_.001.dar.md5
> 1234-2025_2025-08-14T07.16.50_.002.dar
> 1234-2025_2025-08-14T07.16.50_.002.dar.md5
> ...
> 1234-2025_2025-08-14T07.16.50_.204.dar
> 1234-2025_2025-08-14T07.16.50_.204.dar.md5
> 
> Each slice has a size of 50 GiB.
> 
> Catalog file:
> 
> 1234-2025_2025-08-14T07.16.50_CAT
> 
> Password file:
> 
> 1234-2025_2025-08-14T07.16.50_password.txt
> 
> = Selective Restore =
> 
> == Determining the relevant slice(s) using the catalog file ==
> 
> dar -l 1234-2025_2025-08-14T07.16.50_CAT -Tslice -g "1234-2025/25-0585/test.pdf"
> 
> Output:
> 
> Slice(s)|[Data ][D][ EA  ][FSA][Compr][S]|Permission| Filename
> --------+--------------------------------+----------+-----------------------------
>           [InRef][-]       [---][   0%][ ] drwxrwxrwx 1234-2025
>           [InRef][-]       [---][   3%][ ] drwxrwxrwx 1234-2025/25-0585
> 166      [InRef][ ]       [-L-][-----][X] -rwxrwxrwx 1234-2025/25-0585/test.pdf
> -----
> All displayed files have their data in slice range [166]
> 
> Based on the catalog, the file appears to be fully stored in slice 166.
> 
> == Automatic copying of required slices via -E fails ==
> 
> 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)" \
>      
> 
> This results in:
> 
> cp: cannot stat '/media/ltfs/1234-2025_2025-08-14T07.16.50_.0.dar': No
> such file or directory
> 
> followed by:
> 
> Error during user command line execution: execution of [ cp
> /media/ltfs/1234-2025_2025-08-14T07.16.50_.0.dar
> /media/raid5/restore/temp ] returned error code: 256
> 
> If I explicitly add --min-digits 3, I instead get:
> 
> Error during user command line execution: execution of [ cp
> /media/ltfs/1234-2025_2025-08-14T07.16.50_.000.dar
> /media/raid5/restore/temp ] returned error code: 256
 > > I have read the following note:
> 
> “Note that dar will initially require slice number zero, meaning the
> last slice of the backup...”
> 
> However, I assumed that this behavior would not be required when using
> a separate catalog file.

it is because you can change the slicing of an archive even after having 
created an isolated catalog. Thus the last slice cannot be known, but no 
worries, you can drive for dar request the first slice (read below).

And yes, the table of content is loaded from the isolated catalogue, but 
there is still the archive format version to read from the 
backup/archive (which may differ from the isolated catalog if different 
version of dar have been used between backup and isolation). This 
information is located both at the beginning of the first slice and a 
the end of the last slice (which is where it is fetched by default).

You should consider using the -affs option (--alter=force-first-slice)
to fetch this information from the first slice, and use a tiny first 
slice ("-S 1k"(uppercase S) 1 KB is large enough for that). This way, 
you could store on disk only this tiny first slice and the isolated 
catalogue. Then using the -affs option, you will only load from tape the 
big slices requested to restore a particular file or set of files.

Yes, there is room to improve things, this is something under 
consideration for version 2.9.0.

In the meanwhile you can either store the first or the last slice out of 
tape, which ever is the smaller beside the catalog and only use -affs if 
the smaller is the first. For your next backup, you will surely create a 
tiny first slice...

> 
> == Restore with only slice 166 and catalog still fails ==
> 
> Even if I manually copy the required slice file (slice 166), the
> restore still only works if the last slice is also present, although
> the catalog file is provided:
> 
> 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)"
> 
> Output:
> 
> Auto detecting min-digits to be 3
> The last file of the set is not present ..., please provide it.
> 
> == Additional observation regarding -E behavior ==
> 
> I also observed that the command triggered by -E deletes a manually
> provided last slice and then copies it again.

if you mean the following argument you passed to dar:
	-E "cp /media/ltfs/%b.%N.%e %p"

well... dar, by itself does not delete slices...

But yes, this is the way the 'cp' unix command works. If you do not want 
this behavior, better using:
	-E "cp -n /media/ltfs/%b.%N.%e %p"

(-n option of the unix cp command).

> 
> It seems that the last slice is only required as a placeholder. In
> fact, I can create it using:
> 
> touch 1234-2025_2025-08-14T07.16.50_.204.dar

this is not what I observe: I get this error message if I "touch" the 
last slice rather than copying it:
backup.5.dar has a bad or corrupted header, please provide the correct 
file. [return = YES | Esc = NO]

> 
> and the restore proceeds. This means that copying the full last slice
> from tape could be avoided, saving time and bandwidth depending on
> slice size.

If so, replacing the -E option with the following script should solve 
your problem:
	-E "my_script.duc %p %b %N %e %c"

 > cat my_script.duc
#!/bin/bash

slicepath="/media/ltfs"
slicename="$2.$3.$4"
target="$1"

if [ "$5" = "init" ] ; then
    touch "$target/$slicename"
else
    cp -n "$slicepath/$slicename" "$target"
fi
 >

But I would be surprise if it was not issuing the warning I had while 
creating the last slice using "touch".
[note that I have not tested this above script, it may fails upon syntax 
error, this is just here to expose the idea]

> 
> Is this behavior expected or known?

yes, so far.

> 
> == 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.

> Is it mandatory to also specify
> --min-digits 3, or is this behavior caused by DAR requiring the last
> slice despite the presence of a catalog file?

today, dar check the location where slices are to be read and determin 
the min-digit automatically. However, if there is no slice at all, 
obviously you need to provide the --min-digits argument for the -E 
option and its %N macro set the proper number of leader zeros...

> Why does DAR require the last slice during extraction even when a
> separate catalog file is provided with -A? 

should now have the answer from answer above, see also man page 
regarding -affs option to get more details.

> This reduces robustness, as
> the last slice must always be present and intact, even if the
> requested file resides in a different slice.

the last or the first slice.

> Is the behavior of deleting and re-copying the last slice via -E
> expected? 

-E is doing what the user tells it to run... nothing more, nothing less ;)

> And is it intentional that a zero-length placeholder file is
> sufficient for the restore process?

it is not and it should unfortunately not work, check with the script I 
provided and let me know.

> 
> Best regards,
> 
> Ralf
> 

Cheers,
Denis

[Dar-support] Questions about selective restore, slice handling and -E behavior with and catalog-file

[Moll, R. <me...@rm...>]

Hello Denis,

first of all, I would like to thank you for your excellent tool. I am
currently using DAR in an extended proof of concept in our HQ to
archive individual cases to LTFS-formatted LTO-8 tapes in a
data-protection-compliant way.

= DAR Version =
dar version 2.7.8 on Debian 12

= Backup Creation =

BCK_PAR="--min-digits 3 -s 51200M --hash md5 -vt -vm -M"
dar ${BCK_PAR} -@ "${BCK_CAT}CAT" -c "${BCK_DST}" -R "${BCK_SRC_DIR}"
-g "${BCK_SRC_BASE}" -Kaes:${BCK_PAS}

= Created Files =

Slices:

1234-2025_2025-08-14T07.16.50_.001.dar
1234-2025_2025-08-14T07.16.50_.001.dar.md5
1234-2025_2025-08-14T07.16.50_.002.dar
1234-2025_2025-08-14T07.16.50_.002.dar.md5
...
1234-2025_2025-08-14T07.16.50_.204.dar
1234-2025_2025-08-14T07.16.50_.204.dar.md5

Each slice has a size of 50 GiB.

Catalog file:

1234-2025_2025-08-14T07.16.50_CAT

Password file:

1234-2025_2025-08-14T07.16.50_password.txt

= Selective Restore =

== Determining the relevant slice(s) using the catalog file ==

dar -l 1234-2025_2025-08-14T07.16.50_CAT -Tslice -g "1234-2025/25-0585/test.pdf"

Output:

Slice(s)|[Data ][D][ EA  ][FSA][Compr][S]|Permission| Filename
--------+--------------------------------+----------+-----------------------------
         [InRef][-]       [---][   0%][ ] drwxrwxrwx 1234-2025
         [InRef][-]       [---][   3%][ ] drwxrwxrwx 1234-2025/25-0585
166      [InRef][ ]       [-L-][-----][X] -rwxrwxrwx 1234-2025/25-0585/test.pdf
-----
All displayed files have their data in slice range [166]

Based on the catalog, the file appears to be fully stored in slice 166.

== Automatic copying of required slices via -E fails ==

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"

This results in:

cp: cannot stat '/media/ltfs/1234-2025_2025-08-14T07.16.50_.0.dar': No
such file or directory

followed by:

Error during user command line execution: execution of [ cp
/media/ltfs/1234-2025_2025-08-14T07.16.50_.0.dar
/media/raid5/restore/temp ] returned error code: 256

If I explicitly add --min-digits 3, I instead get:

Error during user command line execution: execution of [ cp
/media/ltfs/1234-2025_2025-08-14T07.16.50_.000.dar
/media/raid5/restore/temp ] returned error code: 256

I have read the following note:

“Note that dar will initially require slice number zero, meaning the
last slice of the backup...”

However, I assumed that this behavior would not be required when using
a separate catalog file.

== Restore with only slice 166 and catalog still fails ==

Even if I manually copy the required slice file (slice 166), the
restore still only works if the last slice is also present, although
the catalog file is provided:

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)"

Output:

Auto detecting min-digits to be 3
The last file of the set is not present ..., please provide it.

== Additional observation regarding -E behavior ==

I also observed that the command triggered by -E deletes a manually
provided last slice and then copies it again.

It seems that the last slice is only required as a placeholder. In
fact, I can create it using:

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

and the restore proceeds. This means that copying the full last slice
from tape could be avoided, saving time and bandwidth depending on
slice size.

Is this behavior expected or known?

== 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. Is it mandatory to also specify
--min-digits 3, or is this behavior caused by DAR requiring the last
slice despite the presence of a catalog file?
Why does DAR require the last slice during extraction even when a
separate catalog file is provided with -A? This reduces robustness, as
the last slice must always be present and intact, even if the
requested file resides in a different slice.
Is the behavior of deleting and re-copying the last slice via -E
expected? And is it intentional that a zero-length placeholder file is
sufficient for the restore process?

Best regards,

Ralf

Re: [Dar-support] --sequential-read fails: Skipping backward is not possible on a pipe

[Denis C. <dar...@fr...>]

Hi Adam,

OK, problem found, understood and solved. You should not have
to change your backup, this was just a data processing/reading bug.

You have the 2.8.4.RC1 release candidate available at:
https://dar.edrusb.org/dar.linux.free.fr/Interim_releases/

currently building a dar_static version for x86_64 if that can help,
it will be placed beside source package when available.

non-regression tests will run for a big week then the 2.8.4 will be 
released, if no problem has been found in the meantime.

Thank you for your feedback and script to reproduce the bug, this helped 
and saved me a lot of time!

Cheers,
Denis

Le 10/03/2026 à 23:35, Denis Corbin via Dar-support a écrit :
> Le 08/03/2026 à 03:29, Adam Watkins a écrit :
>> Hello,
> 
> Hello,
> 
> my message sent on Sunday does not show in the mailing-list, I assume it 
> has been lost...
> 
>>
>> I believe I may have found an issue with DAR sequential streaming on 
>> pipes in version 2.8.3.
>>
>> Environment:
>> OS: Bazzite
>> dar version 2.8.3
>> libdar 7.0.2
>> compiled Feb 19 2026
>> Linux (x86_64)
>>
> 
> Thanks for this contextual info!
> What is the archive header? [output of "dar -l <archive> -q"]
> 
>> After generating an archive, a later test with dar -t works, however 
>> with dar --sequential-read -t -, it does not, generating the following 
>> error and several paths that do not exist in my archive, root dir 
>> items appearing below the first error and this directory keeps growing 
>> as the error occurs.
>>
>> Skipping backward is not possible on a pipe
> 
> this is obviously a bug...
> 
>>
>> This is for a tape workflow, with dar_xform and mbuffer etc, but I 
>> isolated the problem to sequential-read from dar.
>>
>> dar ... -c - | dar --sequential-read -t -
>>
>> If needed, I can provide additional logs or test cases.
> 
> Yes, it would worth knowing the few first lines of output when starts 
> the loop you describe including a couple of lines that succeeded the 
> test right before.
> 
> Also, the same portion of the archive testing in non-sequential read 
> mode would help.
> 
> You can send me that directly by email to keep this information as 
> private as possible if you want or you can share it here if you prefer.
> 
>>
>> Thanks,
>> Adam
>>
>>
> 
> Regards,
> Denis
> 

Re: [Dar-support] --sequential-read fails: Skipping backward is not possible on a pipe

[Denis C. <dar...@fr...>]

Le 08/03/2026 à 03:29, Adam Watkins a écrit :
> Hello,

Hello,

my message sent on Sunday does not show in the mailing-list, I assume it 
has been lost...

> 
> I believe I may have found an issue with DAR sequential streaming on 
> pipes in version 2.8.3.
> 
> Environment:
> OS: Bazzite
> dar version 2.8.3
> libdar 7.0.2
> compiled Feb 19 2026
> Linux (x86_64)
> 

Thanks for this contextual info!
What is the archive header? [output of "dar -l <archive> -q"]

> After generating an archive, a later test with dar -t works, however 
> with dar --sequential-read -t -, it does not, generating the following 
> error and several paths that do not exist in my archive, root dir items 
> appearing below the first error and this directory keeps growing as the 
> error occurs.
> 
> Skipping backward is not possible on a pipe

this is obviously a bug...

> 
> This is for a tape workflow, with dar_xform and mbuffer etc, but I 
> isolated the problem to sequential-read from dar.
> 
> dar ... -c - | dar --sequential-read -t -
> 
> If needed, I can provide additional logs or test cases.

Yes, it would worth knowing the few first lines of output when starts 
the loop you describe including a couple of lines that succeeded the 
test right before.

Also, the same portion of the archive testing in non-sequential read 
mode would help.

You can send me that directly by email to keep this information as 
private as possible if you want or you can share it here if you prefer.

> 
> Thanks,
> Adam
> 
> 

Regards,
Denis

[Dar-support] --sequential-read fails: Skipping backward is not possible on a pipe

[Adam W. <acw...@gm...>]

Hello,

I believe I may have found an issue with DAR sequential streaming on pipes
in version 2.8.3.

Environment:
OS: Bazzite
dar version 2.8.3
libdar 7.0.2
compiled Feb 19 2026
Linux (x86_64)

After generating an archive, a later test with dar -t works, however with
dar --sequential-read -t -, it does not, generating the following error and
several paths that do not exist in my archive, root dir items appearing
below the first error and this directory keeps growing as the error occurs.

Skipping backward is not possible on a pipe

This is for a tape workflow, with dar_xform and mbuffer etc, but I isolated
the problem to sequential-read from dar.

dar ... -c - | dar --sequential-read -t -

If needed, I can provide additional logs or test cases.

Thanks,
Adam

[Dar-support] `dar-backup` v2 – follow-up announcement (since v2-0.6.17)

[Per J. <per...@pm...>]

Hello,

Mar 29, 2025 I announced early v2 work around "v2-0.6.17".
I would like to provide a follow-up: `dar-backup` v2 has matured 
significantly and is now in a stable state.

Since v2-0.6.17:

  *

    Catalog handling has been redesigned; FULL/DIFF/INCR chains are
    resolved automatically and Point-In-Time restore is supported.

  * Configurable Restore tests are executed automatically after backup
    creation.
  *

    A full unit and integration test suite has been added, covering
    backup, verification, restore, and cleanup workflows.

  *

    Per-backup PAR2 redundancy configuration is supported (ratio and
    placement configurable per definition).

  *

    Logging and error handling have been hardened.

  *

    Documentation has been reorganized and expanded.

The tool is currently validated against `dar` 2.7.19.
I will begin testing against the 2.8.x series next.

Next planned area of work is integration with dar’s PKI-based encryption 
features, allowing certificate-driven encryption (perhaps) per backup 
definition.

Feedback is welcome, particularly from users running `dar` 2.8.x:
https://github.com/per2jensen/dar-backup<https://github.com/per2jensen/dar-backup>

Best regards,
Per Jensen

Re: [Dar-support] Error while opening libgcrypt key handle to check password strength: gcrypt/Out of memory

[Denis C. <dar...@fr...>]

Le 19/01/2026 à 11:45, and...@vi... a écrit :
> 
>> Il 18/01/2026 19:38 CET Denis Corbin via Dar-support <dar-
>> su...@li...> ha scritto:
>> 
>> 
>> Le 18/01/2026 à 10:01, andycapo--- via Dar-support a écrit :

[...]

>> 
> 
> First of all, I just tried the interim release for 2.8.3 ( https://
> dar.edrusb.org/dar.linux.free.fr/Interim_releases/
> dar_static_2.8.3.RC1_x86_64_GNU_Linux ) and works (without forcing -
> G 1,n) on the backup that caused troubles. Thank you!

Great, thanks for this feedback!

> 
> I however decided to build the package (as I always did in the past)
> by myself, this time I used the Opensuse Build Service (it is really
> practical, no need to install local devel-related dependencies).
> 
> 1. You will find the complete setup freely available in https://
> build.opensuse.org/package/show/home:andycapo/dar28
> 
> 2. In particular I modified slightly the configuration file of the
> "standard" dar opensuse build, for building version 2.8.2: https://
> build.opensuse.org/projects/home:andycapo/packages/dar28/files/
> dar.spec?expand=1 In this file you can see the list of dependencies.

Wonderful!!!   8)
Thank you very much for this work!

> 
> 3. Packages generated are available for the opensuse 16.0 x64
> flavour in: https://build.opensuse.org/projects/home:andycapo/
> packages/dar28/repositories/16.0/binaries
> 
> 4. The quickest way to install these packages (in opensuse 16.0 x64)
> is issuing the following commands:
> 
> sudo zypper addrepo \ https://download.opensuse.org/repositories/
> home:andycapo/16.0/home:andycapo.repo sudo zypper refresh sudo
> zypper in dar libdar64-7000 dar-doc dar-lang
> 
> 5. I don’t promise to actively maintain this repo — I’ll probably
> update it only if I really need it. Think of it more as a personal
> project than a proper repo service.

no worries, this will stay a good starting point to self build and
create packages under OpenSuse

> 
>> But well, I will however see how to add dar_manager and other
>> command line tools provided beside dar, in a static flavor, but
>> this will be for a next major release, so not in the next coming
>> months, I'm afraid...
> 
> Many thanks, I'm sure having a static version of all commands is
> surely a good thing.
> 
>> 
>> Cheers, Denis
>> 
>> [...]
> 
> Cheers, Andy

Re: [Dar-support] Error while opening libgcrypt key handle to check password strength: gcrypt/Out of memory

[<and...@vi...>]

> Il 18/01/2026 19:38 CET Denis Corbin via Dar-support <dar...@li...> ha scritto:
> 
>  
> Le 18/01/2026 à 10:01, andycapo--- via Dar-support a écrit :
> > Hello Denis,
> 
> Hello Andy,
> 

Hello Denis,

> > a side-request non directly related to the issue. I would like to
> > use the newer dar static version (2.8.x) in my backup chain, using
> > your statically built executable. The problem I'm facing is that
> > dar_manager is the standard version installed on my linux opensuse
> > 16.0 (dar 2.7.15) ~/test $ dar_manager -V
> > 
> > dar_manager version 1.8.3, Copyright (C) 2002-2020 Denis Corbin
> > 
> > and it is unable to deal with the catalogues generated with the
> > newer dar
> > 
> > ~/test $ dar_manager -B dbardar -ai -A ardar.cata Unknown flag found
> > in archive header/trailer, ignoring the CRC mismatch possibly due to
> > the unknown corresponding field The format version of the archive is
> > too high for that software version, try reading anyway? [return =
> > YES | Esc = NO] Continuing... FATAL error, aborting operation:
> > Cannot open catalogue: incoherent catalogue structure
> > 
> > Any work-around? May it is possible to generate (with the newer dar)
> > an isolated catalogue in a previous format? Alternatively, could you
> > consider providing the static version of also the utilities and not
> > only the dar executable? Thank you
> 
> since 2.8.0 you can directly use dar (and thus dar_static) to read a
> dar_manager database (see -aefd option), but if you want to modify a
> database, you need dar_manager, correct.
> 
> There is backward compatibility, where newer versions can handle what
> existed before as archive or database format. The opposite is not true
> (how to guess what will be in the future). And sorry there is no way to
> save a database or archive in an older format, as these format evolution
> are needed to store the information related the new/added features.
> 
> I would enjoin you to first ask Suse to upgrade their upstream version,
> they make money with all free software around, including dar, and that's
> great no problem, so they should have more available resources than I
> have.
> 
> A second alternative is to grab the isolated catalogues generated by
> dar_static and feed a dar_manager database somewhere else than this Suse
> plateform with old dar software. Then you will be able to restore things
> on that system only using dar_static, the recent dar_manager database
> and your backups.
> 
> A third alternative is to take the dar 2.8.x sources package, compile
> and install it yourself on you Suse system (an remove all dar package 
> before): it will go to /usr/local by
> default which is usually fine. You will be able to uninstall dar using
> "make uninstall" from the dar source code whenever you'll want to 
> upgrade or remove it (assuming Suse updated their package, for example,
> and you do no more need extra-distro dar version).
> 
> Note that building just a dynamic version is easy, static building is 
> more tricky, so I would not add the --enable-dar-static option to the
> ./configure script for that third alternative stays simple.
> 
> For that you can follow the documentation at
> http://dar.linux.free.fr/doc/from_sources.html
> and at this occasion let me know all the Suse Packages you had to
> install to achieve it, I will then update the documentation with
> the Suse package names. This will be even more easy for any other one,
> looking at doing the same thing in the future.
> 

First of all, I just tried the interim release for 2.8.3 ( https://dar.edrusb.org/dar.linux.free.fr/Interim_releases/dar_static_2.8.3.RC1_x86_64_GNU_Linux ) and works (without forcing -G 1,n) on the backup that caused troubles. Thank you!

I however decided to build the package (as I always did in the past) by myself, this time I used the Opensuse Build Service (it is really practical, no need to install local devel-related dependencies).

1. You will find the complete setup freely available in
https://build.opensuse.org/package/show/home:andycapo/dar28

2. In particular I modified slightly the configuration file of the "standard" dar opensuse build, for building version 2.8.2:
https://build.opensuse.org/projects/home:andycapo/packages/dar28/files/dar.spec?expand=1
In this file you can see the list of dependencies.

3. Packages generated are available for the opensuse 16.0 x64 flavour in:
https://build.opensuse.org/projects/home:andycapo/packages/dar28/repositories/16.0/binaries

4. The quickest way to install these packages (in opensuse 16.0 x64) is issuing the following commands:

sudo zypper addrepo \
https://download.opensuse.org/repositories/home:andycapo/16.0/home:andycapo.repo
sudo zypper refresh
sudo zypper in dar libdar64-7000 dar-doc dar-lang

5. I don’t promise to actively maintain this repo — I’ll probably update it only if I really need it. Think of it more as a personal project than a proper repo service.

> But well, I will however see how to add dar_manager and other command
> line tools provided beside dar, in a static flavor, but this
> will be for a next major release, so not in the next coming months, I'm
> afraid...

Many thanks, I'm sure having a static version of all commands is surely a good thing.

> 
> Cheers,
> Denis
> 
> [...]

Cheers,
Andy

Re: [Dar-support] Error while opening libgcrypt key handle to check password strength: gcrypt/Out of memory

[Denis C. <dar...@fr...>]

Le 17/01/2026 à 17:22, and...@vi... a écrit :
> Hello,
[...]
> 
> I'm using aes256 (-K aes:...) compression.
> I just tried with -G 1,6 and worked. If I set -G 2,2 the "Out of memory" error occours.
> Many thanks for the quick solution!

the problem was related to libssh library, which libdar relies on for 
sftp feature, that initializes libgcrypt in a way that was not 
compatible for this later library to provide strong encryption feature 
(they say a library should not initialize another library it relies on, 
but let that part to the non-library calling code...).

The fix was to build libssh not to rely on libgcrypt but on openssl 
(hopefully libssh has two modes of being built) so that way it does not 
interfere with libgcrypt initialization and strong encryption feature.

You can find source code and dar_static for 2.8.3.RC1 (release 
candidate) at:
https://dar.edrusb.org/dar.linux.free.fr/Interim_releases/

Release 2.8.3 will take place once non-regression tests will have completed.

Cheers,
Denis

Re: [Dar-support] Error while opening libgcrypt key handle to check password strength: gcrypt/Out of memory

[Denis C. <dar...@fr...>]

Le 18/01/2026 à 10:01, andycapo--- via Dar-support a écrit :
> Hello Denis,

Hello Andy,

> a side-request non directly related to the issue. I would like to
> use the newer dar static version (2.8.x) in my backup chain, using
> your statically built executable. The problem I'm facing is that
> dar_manager is the standard version installed on my linux opensuse
> 16.0 (dar 2.7.15) ~/test $ dar_manager -V
> 
> dar_manager version 1.8.3, Copyright (C) 2002-2020 Denis Corbin
> 
> and it is unable to deal with the catalogues generated with the
> newer dar
> 
> ~/test $ dar_manager -B dbardar -ai -A ardar.cata Unknown flag found
> in archive header/trailer, ignoring the CRC mismatch possibly due to
> the unknown corresponding field The format version of the archive is
> too high for that software version, try reading anyway? [return =
> YES | Esc = NO] Continuing... FATAL error, aborting operation:
> Cannot open catalogue: incoherent catalogue structure
> 
> Any work-around? May it is possible to generate (with the newer dar)
> an isolated catalogue in a previous format? Alternatively, could you
> consider providing the static version of also the utilities and not
> only the dar executable? Thank you

since 2.8.0 you can directly use dar (and thus dar_static) to read a
dar_manager database (see -aefd option), but if you want to modify a
database, you need dar_manager, correct.

There is backward compatibility, where newer versions can handle what
existed before as archive or database format. The opposite is not true
(how to guess what will be in the future). And sorry there is no way to
save a database or archive in an older format, as these format evolution
are needed to store the information related the new/added features.

I would enjoin you to first ask Suse to upgrade their upstream version,
they make money with all free software around, including dar, and that's
great no problem, so they should have more available resources than I
have.

A second alternative is to grab the isolated catalogues generated by
dar_static and feed a dar_manager database somewhere else than this Suse
plateform with old dar software. Then you will be able to restore things
on that system only using dar_static, the recent dar_manager database
and your backups.

A third alternative is to take the dar 2.8.x sources package, compile
and install it yourself on you Suse system (an remove all dar package 
before): it will go to /usr/local by
default which is usually fine. You will be able to uninstall dar using
"make uninstall" from the dar source code whenever you'll want to 
upgrade or remove it (assuming Suse updated their package, for example,
and you do no more need extra-distro dar version).

Note that building just a dynamic version is easy, static building is 
more tricky, so I would not add the --enable-dar-static option to the
./configure script for that third alternative stays simple.

For that you can follow the documentation at
http://dar.linux.free.fr/doc/from_sources.html
and at this occasion let me know all the Suse Packages you had to
install to achieve it, I will then update the documentation with
the Suse package names. This will be even more easy for any other one,
looking at doing the same thing in the future.

But well, I will however see how to add dar_manager and other command
line tools provided beside dar, in a static flavor, but this
will be for a next major release, so not in the next coming months, I'm
afraid...

Cheers,
Denis

[...]

Re: [Dar-support] Error while opening libgcrypt key handle to check password strength: gcrypt/Out of memory

[<and...@vi...>]

Hello Denis,
   a side-request non directly related to the issue.
I would like to use the newer dar static version (2.8.x) in my backup chain, using your statically built executable.
The problem I'm facing is that dar_manager is the standard version installed on my linux opensuse 16.0 (dar 2.7.15)
~/test $ dar_manager -V

 dar_manager version 1.8.3, Copyright (C) 2002-2020 Denis Corbin

and it is unable to deal with the catalogues generated with the newer dar

~/test $ dar_manager -B dbardar -ai -A ardar.cata
Unknown flag found in archive header/trailer, ignoring the CRC mismatch possibly due to the unknown corresponding field
The format version of the archive is too high for that software version, try reading anyway? [return = YES | Esc = NO]
Continuing...
FATAL error, aborting operation: Cannot open catalogue: incoherent catalogue structure

Any work-around? May it is possible to generate (with the newer dar) an isolated catalogue in a previous format?
Alternatively, could you consider providing the static version of also the utilities and not only the dar executable?
Thank you

> Il 17/01/2026 16:02 CET Denis Corbin via Dar-support <dar...@li...> ha scritto:
> 
>  
> Le 17/01/2026 à 12:06, andycapo--- via Dar-support a écrit :
> > Hello, I'm an old dar user (and always I have to thank Denis for this 
> > wonderful software).
> 
> you are welcome!
> 
> > 
> > I have a problem with the static version 2.8.2 ( https://dar.edrusb.org/ 
> > dar.linux.free.fr/Releases/Dar_static/x86_64_GNU_Linux/ 
> > dar_static_2.8.2_x86_64_GNU_Linux <https://dar.edrusb.org/ 
> > dar.linux.free.fr/Releases/Dar_static/x86_64_GNU_Linux/ 
> > dar_static_2.8.2_x86_64_GNU_Linux> ), as I get the following error:
> > 
> > ---
> > 
> > sudo /home/usr002/opt/bin/dar_static_2.8.2_x86_64_GNU_Linux -c "/mnt/ 
> > usb/SG18/midar/data_usr002/20260117T102020_incr" -R "/mnt/usb/WD8" -g 
> > "data_usr002" -A "/mnt/usb/SG18/midar/data_usr002/20260101T164341_incr" 
> > -B "/home/usr002/opt/tools/midar/midar.dcf" -va
> > User target found on command line or included file(s):
> > compress-exclusion
> > Opening archive 20260101T164341_incr ...
> > Opening the archive using the multi-slice abstraction layer...
> > Reading the archive trailer...
> > Opening construction layer...
> > Considering cyphering layer...
> > Opening cyphering layer...
> > multi-threaded cyphering layer open, with 2 worker thread(s)
> > Opening escape sequence abstraction layer...
> > Opening the compression layer...
> > streamed compression layer open (single threaded)
> > All layers have been created successfully
> > Warning, the archive 20260101T164341_incr has been encrypted. A wrong 
> > key is not possible to detect, it would cause DAR to report the archive 
> > as corrupted
> > Loading catalogue into memory...
> > Locating archive contents...
> > Reading archive contents...
> > Creating low layer: Writing archive into a sar object (Segmentation and 
> > Reassembly) for slicing...
> > Adding a new layer on top: Strong encryption object...
> > Aborting due to exception: Error creating archive layers: Error while 
> > opening libgcrypt key handle to check password strength: gcrypt/Out of 
> > memory
> > Final memory cleanup
> > Error creating archive layers: Error while opening libgcrypt key handle 
> > to check password strength: gcrypt/Out of memory
> > 
> > ---
> > 
> > With the standard version installed on my linux opensuse 16.0 (dar 
> > 2.7.15) I have no problems.
> > 
> > Any suggestion?
> > Thanks in advance
> 
> Yes, this looks like the know problem reported at github and currently 
> still under investigations:
> 
> https://github.com/Edrusb/DAR/issues/70
> 
> This is not simple: at first I had to increase the stack size because of 
> the musl library I used to build dar_static (musl replacing the glibc 
> which does not well support static library, for that I had to use 
> voidLinux distro). This solved some issues, but still remains the 
> twofish algorithm that does not work using several thread, but works 
> when using only a single thread. Thus if you are using this encryption 
> algo with dar_static you currently need to add "-G 1,n" option, where n 
>  >=1 and is the number of thread you want to use for 
> compression/decompression. What encryption algo are you using?
> 
> I added a parameter to specify the amount of secured memory reserved by 
> dar at library initialization, as well as another to specify the stack 
> size to use for libdar threads... depending on the outcome of problem I 
> will merge these "features" either to the branch_2.8.x or to the master 
> (dev) code... Anyway adding ashamed big amount of secured memory and 
> stack size does not solve the issue, but helps on some points.
> 
> Currently I moved to a fresh Debian trixie install (thus using glibc as 
> standard C library) and found yesterday that libssh should not be 
> compiled relying on libcrypto to solve this issue. But I have still to 
> add some other dependencies, one by one, then test, eventually recompile 
> them... so it takes time.
> 
> Can you try -G 1,n option and tell me if that workaround works for you?
> 
> > 
> > 
> 
> Thanks,
> Denis

Re: [Dar-support] Error while opening libgcrypt key handle to check password strength: gcrypt/Out of memory

[<and...@vi...>]

Hello,

> [...]
> > Aborting due to exception: Error creating archive layers: Error while 
> > opening libgcrypt key handle to check password strength: gcrypt/Out of 
> > memory
> > Final memory cleanup
> > Error creating archive layers: Error while opening libgcrypt key handle 
> > to check password strength: gcrypt/Out of memory
> > 
> > ---
> > 
> > With the standard version installed on my linux opensuse 16.0 (dar 
> > 2.7.15) I have no problems.
> > 
> > Any suggestion?
> > Thanks in advance
> 
> Yes, this looks like the know problem reported at github and currently 
> still under investigations:
> 
> https://github.com/Edrusb/DAR/issues/70
> 
> This is not simple: at first I had to increase the stack size because of 
> the musl library I used to build dar_static (musl replacing the glibc 
> which does not well support static library, for that I had to use 
> voidLinux distro). This solved some issues, but still remains the 
> twofish algorithm that does not work using several thread, but works 
> when using only a single thread. Thus if you are using this encryption 
> algo with dar_static you currently need to add "-G 1,n" option, where n 
>  >=1 and is the number of thread you want to use for 
> compression/decompression. What encryption algo are you using?
> 
> I added a parameter to specify the amount of secured memory reserved by 
> dar at library initialization, as well as another to specify the stack 
> size to use for libdar threads... depending on the outcome of problem I 
> will merge these "features" either to the branch_2.8.x or to the master 
> (dev) code... Anyway adding ashamed big amount of secured memory and 
> stack size does not solve the issue, but helps on some points.
> 
> Currently I moved to a fresh Debian trixie install (thus using glibc as 
> standard C library) and found yesterday that libssh should not be 
> compiled relying on libcrypto to solve this issue. But I have still to 
> add some other dependencies, one by one, then test, eventually recompile 
> them... so it takes time.
> 
> Can you try -G 1,n option and tell me if that workaround works for you?
> 
> Thanks,
> Denis

I'm using aes256 (-K aes:...) compression.
I just tried with -G 1,6 and worked. If I set -G 2,2 the "Out of memory" error occours.
Many thanks for the quick solution!

Re: [Dar-support] Error while opening libgcrypt key handle to check password strength: gcrypt/Out of memory

[Denis C. <dar...@fr...>]

Le 17/01/2026 à 12:06, andycapo--- via Dar-support a écrit :
> Hello, I'm an old dar user (and always I have to thank Denis for this 
> wonderful software).

you are welcome!

> 
> I have a problem with the static version 2.8.2 ( https://dar.edrusb.org/ 
> dar.linux.free.fr/Releases/Dar_static/x86_64_GNU_Linux/ 
> dar_static_2.8.2_x86_64_GNU_Linux <https://dar.edrusb.org/ 
> dar.linux.free.fr/Releases/Dar_static/x86_64_GNU_Linux/ 
> dar_static_2.8.2_x86_64_GNU_Linux> ), as I get the following error:
> 
> ---
> 
> sudo /home/usr002/opt/bin/dar_static_2.8.2_x86_64_GNU_Linux -c "/mnt/ 
> usb/SG18/midar/data_usr002/20260117T102020_incr" -R "/mnt/usb/WD8" -g 
> "data_usr002" -A "/mnt/usb/SG18/midar/data_usr002/20260101T164341_incr" 
> -B "/home/usr002/opt/tools/midar/midar.dcf" -va
> User target found on command line or included file(s):
> compress-exclusion
> Opening archive 20260101T164341_incr ...
> Opening the archive using the multi-slice abstraction layer...
> Reading the archive trailer...
> Opening construction layer...
> Considering cyphering layer...
> Opening cyphering layer...
> multi-threaded cyphering layer open, with 2 worker thread(s)
> Opening escape sequence abstraction layer...
> Opening the compression layer...
> streamed compression layer open (single threaded)
> All layers have been created successfully
> Warning, the archive 20260101T164341_incr has been encrypted. A wrong 
> key is not possible to detect, it would cause DAR to report the archive 
> as corrupted
> Loading catalogue into memory...
> Locating archive contents...
> Reading archive contents...
> Creating low layer: Writing archive into a sar object (Segmentation and 
> Reassembly) for slicing...
> Adding a new layer on top: Strong encryption object...
> Aborting due to exception: Error creating archive layers: Error while 
> opening libgcrypt key handle to check password strength: gcrypt/Out of 
> memory
> Final memory cleanup
> Error creating archive layers: Error while opening libgcrypt key handle 
> to check password strength: gcrypt/Out of memory
> 
> ---
> 
> With the standard version installed on my linux opensuse 16.0 (dar 
> 2.7.15) I have no problems.
> 
> Any suggestion?
> Thanks in advance

Yes, this looks like the know problem reported at github and currently 
still under investigations:

https://github.com/Edrusb/DAR/issues/70

This is not simple: at first I had to increase the stack size because of 
the musl library I used to build dar_static (musl replacing the glibc 
which does not well support static library, for that I had to use 
voidLinux distro). This solved some issues, but still remains the 
twofish algorithm that does not work using several thread, but works 
when using only a single thread. Thus if you are using this encryption 
algo with dar_static you currently need to add "-G 1,n" option, where n 
 >=1 and is the number of thread you want to use for 
compression/decompression. What encryption algo are you using?

I added a parameter to specify the amount of secured memory reserved by 
dar at library initialization, as well as another to specify the stack 
size to use for libdar threads... depending on the outcome of problem I 
will merge these "features" either to the branch_2.8.x or to the master 
(dev) code... Anyway adding ashamed big amount of secured memory and 
stack size does not solve the issue, but helps on some points.

Currently I moved to a fresh Debian trixie install (thus using glibc as 
standard C library) and found yesterday that libssh should not be 
compiled relying on libcrypto to solve this issue. But I have still to 
add some other dependencies, one by one, then test, eventually recompile 
them... so it takes time.

Can you try -G 1,n option and tell me if that workaround works for you?

> 
> 

Thanks,
Denis

[Dar-support] Error while opening libgcrypt key handle to check password strength: gcrypt/Out of memory

[<and...@vi...>]

Hello, I'm an old dar user (and always I have to thank Denis for this wonderful software).

I have a problem with the static version 2.8.2 ( https://dar.edrusb.org/dar.linux.free.fr/Releases/Dar_static/x86_64_GNU_Linux/dar_static_2.8.2_x86_64_GNU_Linux ), as I get the following error:

---

sudo /home/usr002/opt/bin/dar_static_2.8.2_x86_64_GNU_Linux -c "/mnt/usb/SG18/midar/data_usr002/20260117T102020_incr" -R "/mnt/usb/WD8" -g "data_usr002" -A "/mnt/usb/SG18/midar/data_usr002/20260101T164341_incr" -B "/home/usr002/opt/tools/midar/midar.dcf" -va
User target found on command line or included file(s):
compress-exclusion
Opening archive 20260101T164341_incr ...
Opening the archive using the multi-slice abstraction layer...
Reading the archive trailer...
Opening construction layer...
Considering cyphering layer...
Opening cyphering layer...
multi-threaded cyphering layer open, with 2 worker thread(s)
Opening escape sequence abstraction layer...
Opening the compression layer...
streamed compression layer open (single threaded)
All layers have been created successfully
Warning, the archive 20260101T164341_incr has been encrypted. A wrong key is not possible to detect, it would cause DAR to report the archive as corrupted
Loading catalogue into memory...
Locating archive contents...
Reading archive contents...
Creating low layer: Writing archive into a sar object (Segmentation and Reassembly) for slicing...
Adding a new layer on top: Strong encryption object...
Aborting due to exception: Error creating archive layers: Error while opening libgcrypt key handle to check password strength: gcrypt/Out of memory
Final memory cleanup
Error creating archive layers: Error while opening libgcrypt key handle to check password strength: gcrypt/Out of memory

---

With the standard version installed on my linux opensuse 16.0 (dar 2.7.15) I have no problems.

Any suggestion?
Thanks in advance

Re: [Dar-support] Fwd: Unexpected password prompt when isolating an encrypted archive

[Denis C. <dar...@fr...>]

This is because, the "reference:" target is only triggered if a -A 
option has been found while parsing command-line+included files at the 
time this target is found in the parsing process.

You should move the '-A test' option before the '-B minimal-darrc' 
option for it works as expected.

Cheers,
Denis

Le 28/12/2025 à 22:47, ogreg--- via Dar-support a écrit :
> The result with same conditions except -v in catalog isolation step:
> 
> sh-5.2$ dar -v -N -B minimal-darrc -A test -C test-cat
> Arguments read from minimal-darrc :
>   "-an"
>   "-R"
>   "/fs/"
>   "-K"
>   "aes:secret"
> 
> No user target found on command line
> Opening archive test ...
> Opening the archive using the multi-slice abstraction layer...
> Reading the archive trailer...
> Opening construction layer...
> Considering cyphering layer...
> Archive test requires a password: Received signal: Interrupt
> 
> Regards, Ole G
> 
> On 26/12/2025 23.33, Denis Corbin via Dar-support wrote:
>> please add -v option as first option to dar, before any -B option.
>> This should show what option is fetched and where from it is fetched
>>
>> this should help troubleshoot the problem
>>
>> Cheers,
>> Denis
>>
>> Le 24/12/2025 à 21:53, ogreg--- via Dar-support a écrit :
>>> I still have the problem, even with your suggestion to darrc and 
>>> reading up on the Conditional Syntax.
>>> If I specify -J on the isolation command line the problem disappears.
>>> See small testcase below.
>>>
>>> Merry Christmas and regards,
>>>
>>> Ole G
>>>
>>> *sh-5.2$ cat minimal-darrc**
>>> ***all:
>>>    -an
>>>    -R /fs/
>>>    -K aes:secret
>>>
>>> reference:
>>>    -J aes:secret
>>>
>>> *sh-5.2$ dar -N -B minimal-darrc -g f/test -c test**
>>> ***Error reading EA for /fs : Error retrieving EA list for /fs : No 
>>> such file or directory
>>> Error reading EA for /fs/f/System Volume Information : Error 
>>> retrieving EA list for /fs/f/System Volume Information : Permission 
>>> denied
>>> Cannot read directory contents: /fs/f/System Volume Information : 
>>> Error opening directory: /fs/f/System Volume Information : Permission 
>>> denied
>>>    --------------------------------------------
>>>   36 inode(s) saved
>>>     including 0 hard link(s) treated
>>>   0 inode(s) changed at the moment of the backup and could not be 
>>> saved properly
>>>   0 byte(s) have been wasted in the archive to resave changing files
>>>   0 inode(s) with only metadata changed
>>>   0 inode(s) not saved (no inode/file change)
>>>   0 inode(s) failed to be saved (filesystem error)
>>>   22 inode(s) ignored (excluded by filters)
>>>   0 inode(s) recorded as deleted from reference backup
>>>   --------------------------------------------
>>>   Total number of inode(s) considered: 58
>>>   --------------------------------------------
>>>   EA saved for 29 inode(s)
>>>   FSA saved for 36 inode(s)
>>>   --------------------------------------------
>>>
>>> *# The above messages are normal for my backups**
>>> **
>>> **sh-5.2$ dar -N -B minimal-darrc -A test -C test-cat**
>>> ***Archive test requires a password: Received signal: Interrupt
>>>
>>> *# I pressed ^C*
>>>
>>> -------- Forwarded Message --------
>>> Subject:     Re: [Dar-support] Unexpected password prompt when 
>>> isolating an encrypted archive
>>> Date:     Tue, 23 Dec 2025 08:36:56 +0100
>>> From:     og...@gm...
>>> To:     Denis Corbin via Dar-support <dar...@li...>
>>>
>>>
>>>
>>> Thanks, Denis.
>>>
>>> I see the point, especially the case where the catalog is being 
>>> isolated could need 0, 1 or 2 passwords...
>>>
>>> Regards, Ole G
>>>
>>> On 22/12/2025 21.29, Denis Corbin via Dar-support wrote:
>>>> I guess you make a confusion between -K and -J options
>>>>
>>>> -K is to be used for the object of the operation (the archive you 
>>>> create, the isolated catalog you create, the archive you test, list, 
>>>> extract data from...)
>>>>
>>>> -J option apply to the archive of reference (the one given to -A 
>>>> option), here the archive you take as reference to isolate a catalog.
>>>>
>>>> the same way '-$' option (pay attention to the quote if given on 
>>>> shell prompt), applies to the auxiliary archive of reference (see -@ 
>>>> option)
>>>>
>>>> note that -K is only mandatory if you want to cipher the archive (or 
>>>> isolated catalog, which is just a particular type of archive) about 
>>>> to be created.
>>>>
>>>> When reading an archive, if -K -J or '-$' is not specified and the 
>>>> corresponding archive is ciphered, dar will issue a prompt for you 
>>>> provide the password (this is what you got here without -J option).
>>>>
>>>> I would suggest setting the lennz-darrc file more or less that way:
>>>>
>>>> #-------
>>>> all:
>>>>   -K aes:secret
>>>>
>>>> reference:
>>>>   -J aes:secret
>>>> #-------
>>>>
>>>> I let you read the conditional syntax paragraph in dar man page for 
>>>> more information on that syntax and if you want to do more funny 
>>>> things:
>>>> http://dar.linux.free.fr/doc/man/dar.html#CONDITIONAL%20SYNTAX
>>>>
>>>> Cheers,
>>>> Denis
>>>>
>>>>
>>>> Le 22/12/2025 à 20:30, ogreg--- via Dar-support a écrit :
>>>>> Isolating the catalog from an encrypted archive:
>>>>>
>>>>> /dar -zzstd -N -B lennz-darrc -R /proc/cygdrive -C /proc/cygdrive/ 
>>>>> F/ darback/lennz-1-C-0 -A /proc/cygdrive/F/darback/lennz-1-F-0/
>>>>> Archive lennz-1-F-0 requires a password:
>>>>>
>>>>> lennz-darrc contains the line:
>>>>> *-K aes:secret*
>>>>>
>>>>> The previous steps dar -c, dar -t, and dar -d run with a similar 
>>>>> command line, but are able to used the needed information from 
>>>>> lennz- darrc.
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
> 
> 

[Dar-support] First run to restore all

[Graeme G. <gr...@ge...>]

Just installed dargui 1.3 to an empty machine. My attempt to restore all 
gives a error message
"cannot execute empty command line"
Google can't find an answer. Can you please?
Thanks

-- 
Graeme Gemmill
1 Rose Cottages
Litton Cheney
Dorchester
Dorset
DT2 9AR
01308 482178, 07792 713433

Re: [Dar-support] Fwd: Unexpected password prompt when isolating an encrypted archive

[<og...@gm...>]

The result with same conditions except -v in catalog isolation step:

sh-5.2$ dar -v -N -B minimal-darrc -A test -C test-cat
Arguments read from minimal-darrc :
  "-an"
  "-R"
  "/fs/"
  "-K"
  "aes:secret"

No user target found on command line
Opening archive test ...
Opening the archive using the multi-slice abstraction layer...
Reading the archive trailer...
Opening construction layer...
Considering cyphering layer...
Archive test requires a password: Received signal: Interrupt

Regards, Ole G

On 26/12/2025 23.33, Denis Corbin via Dar-support wrote:
> please add -v option as first option to dar, before any -B option.
> This should show what option is fetched and where from it is fetched
>
> this should help troubleshoot the problem
>
> Cheers,
> Denis
>
> Le 24/12/2025 à 21:53, ogreg--- via Dar-support a écrit :
>> I still have the problem, even with your suggestion to darrc and 
>> reading up on the Conditional Syntax.
>> If I specify -J on the isolation command line the problem disappears.
>> See small testcase below.
>>
>> Merry Christmas and regards,
>>
>> Ole G
>>
>> *sh-5.2$ cat minimal-darrc**
>> ***all:
>>    -an
>>    -R /fs/
>>    -K aes:secret
>>
>> reference:
>>    -J aes:secret
>>
>> *sh-5.2$ dar -N -B minimal-darrc -g f/test -c test**
>> ***Error reading EA for /fs : Error retrieving EA list for /fs : No 
>> such file or directory
>> Error reading EA for /fs/f/System Volume Information : Error 
>> retrieving EA list for /fs/f/System Volume Information : Permission 
>> denied
>> Cannot read directory contents: /fs/f/System Volume Information : 
>> Error opening directory: /fs/f/System Volume Information : Permission 
>> denied
>>    --------------------------------------------
>>   36 inode(s) saved
>>     including 0 hard link(s) treated
>>   0 inode(s) changed at the moment of the backup and could not be 
>> saved properly
>>   0 byte(s) have been wasted in the archive to resave changing files
>>   0 inode(s) with only metadata changed
>>   0 inode(s) not saved (no inode/file change)
>>   0 inode(s) failed to be saved (filesystem error)
>>   22 inode(s) ignored (excluded by filters)
>>   0 inode(s) recorded as deleted from reference backup
>>   --------------------------------------------
>>   Total number of inode(s) considered: 58
>>   --------------------------------------------
>>   EA saved for 29 inode(s)
>>   FSA saved for 36 inode(s)
>>   --------------------------------------------
>>
>> *# The above messages are normal for my backups**
>> **
>> **sh-5.2$ dar -N -B minimal-darrc -A test -C test-cat**
>> ***Archive test requires a password: Received signal: Interrupt
>>
>> *# I pressed ^C*
>>
>> -------- Forwarded Message --------
>> Subject:     Re: [Dar-support] Unexpected password prompt when 
>> isolating an encrypted archive
>> Date:     Tue, 23 Dec 2025 08:36:56 +0100
>> From:     og...@gm...
>> To:     Denis Corbin via Dar-support <dar...@li...>
>>
>>
>>
>> Thanks, Denis.
>>
>> I see the point, especially the case where the catalog is being 
>> isolated could need 0, 1 or 2 passwords...
>>
>> Regards, Ole G
>>
>> On 22/12/2025 21.29, Denis Corbin via Dar-support wrote:
>>> I guess you make a confusion between -K and -J options
>>>
>>> -K is to be used for the object of the operation (the archive you 
>>> create, the isolated catalog you create, the archive you test, list, 
>>> extract data from...)
>>>
>>> -J option apply to the archive of reference (the one given to -A 
>>> option), here the archive you take as reference to isolate a catalog.
>>>
>>> the same way '-$' option (pay attention to the quote if given on 
>>> shell prompt), applies to the auxiliary archive of reference (see -@ 
>>> option)
>>>
>>> note that -K is only mandatory if you want to cipher the archive (or 
>>> isolated catalog, which is just a particular type of archive) about 
>>> to be created.
>>>
>>> When reading an archive, if -K -J or '-$' is not specified and the 
>>> corresponding archive is ciphered, dar will issue a prompt for you 
>>> provide the password (this is what you got here without -J option).
>>>
>>> I would suggest setting the lennz-darrc file more or less that way:
>>>
>>> #-------
>>> all:
>>>   -K aes:secret
>>>
>>> reference:
>>>   -J aes:secret
>>> #-------
>>>
>>> I let you read the conditional syntax paragraph in dar man page for 
>>> more information on that syntax and if you want to do more funny 
>>> things:
>>> http://dar.linux.free.fr/doc/man/dar.html#CONDITIONAL%20SYNTAX
>>>
>>> Cheers,
>>> Denis
>>>
>>>
>>> Le 22/12/2025 à 20:30, ogreg--- via Dar-support a écrit :
>>>> Isolating the catalog from an encrypted archive:
>>>>
>>>> /dar -zzstd -N -B lennz-darrc -R /proc/cygdrive -C 
>>>> /proc/cygdrive/F/ darback/lennz-1-C-0 -A 
>>>> /proc/cygdrive/F/darback/lennz-1-F-0/
>>>> Archive lennz-1-F-0 requires a password:
>>>>
>>>> lennz-darrc contains the line:
>>>> *-K aes:secret*
>>>>
>>>> The previous steps dar -c, dar -t, and dar -d run with a similar 
>>>> command line, but are able to used the needed information from 
>>>> lennz- darrc.
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>

Re: [Dar-support] Fwd: Unexpected password prompt when isolating an encrypted archive

[Denis C. <dar...@fr...>]

please add -v option as first option to dar, before any -B option.
This should show what option is fetched and where from it is fetched

this should help troubleshoot the problem

Cheers,
Denis

Le 24/12/2025 à 21:53, ogreg--- via Dar-support a écrit :
> I still have the problem, even with your suggestion to darrc and reading 
> up on the Conditional Syntax.
> If I specify -J on the isolation command line the problem disappears.
> See small testcase below.
> 
> Merry Christmas and regards,
> 
> Ole G
> 
> *sh-5.2$ cat minimal-darrc**
> ***all:
>    -an
>    -R /fs/
>    -K aes:secret
> 
> reference:
>    -J aes:secret
> 
> *sh-5.2$ dar -N -B minimal-darrc -g f/test -c test**
> ***Error reading EA for /fs : Error retrieving EA list for /fs : No such 
> file or directory
> Error reading EA for /fs/f/System Volume Information : Error retrieving 
> EA list for /fs/f/System Volume Information : Permission denied
> Cannot read directory contents: /fs/f/System Volume Information : Error 
> opening directory: /fs/f/System Volume Information : Permission denied
>    --------------------------------------------
>   36 inode(s) saved
>     including 0 hard link(s) treated
>   0 inode(s) changed at the moment of the backup and could not be saved 
> properly
>   0 byte(s) have been wasted in the archive to resave changing files
>   0 inode(s) with only metadata changed
>   0 inode(s) not saved (no inode/file change)
>   0 inode(s) failed to be saved (filesystem error)
>   22 inode(s) ignored (excluded by filters)
>   0 inode(s) recorded as deleted from reference backup
>   --------------------------------------------
>   Total number of inode(s) considered: 58
>   --------------------------------------------
>   EA saved for 29 inode(s)
>   FSA saved for 36 inode(s)
>   --------------------------------------------
> 
> *# The above messages are normal for my backups**
> **
> **sh-5.2$ dar -N -B minimal-darrc -A test -C test-cat**
> ***Archive test requires a password: Received signal: Interrupt
> 
> *# I pressed ^C*
> 
> -------- Forwarded Message --------
> Subject: 	Re: [Dar-support] Unexpected password prompt when isolating an 
> encrypted archive
> Date: 	Tue, 23 Dec 2025 08:36:56 +0100
> From: 	og...@gm...
> To: 	Denis Corbin via Dar-support <dar...@li...>
> 
> 
> 
> Thanks, Denis.
> 
> I see the point, especially the case where the catalog is being isolated 
> could need 0, 1 or 2 passwords...
> 
> Regards, Ole G
> 
> On 22/12/2025 21.29, Denis Corbin via Dar-support wrote:
>> I guess you make a confusion between -K and -J options
>>
>> -K is to be used for the object of the operation (the archive you 
>> create, the isolated catalog you create, the archive you test, list, 
>> extract data from...)
>>
>> -J option apply to the archive of reference (the one given to -A 
>> option), here the archive you take as reference to isolate a catalog.
>>
>> the same way '-$' option (pay attention to the quote if given on shell 
>> prompt), applies to the auxiliary archive of reference (see -@ option)
>>
>> note that -K is only mandatory if you want to cipher the archive (or 
>> isolated catalog, which is just a particular type of archive) about to 
>> be created.
>>
>> When reading an archive, if -K -J or '-$' is not specified and the 
>> corresponding archive is ciphered, dar will issue a prompt for you 
>> provide the password (this is what you got here without -J option).
>>
>> I would suggest setting the lennz-darrc file more or less that way:
>>
>> #-------
>> all:
>>   -K aes:secret
>>
>> reference:
>>   -J aes:secret
>> #-------
>>
>> I let you read the conditional syntax paragraph in dar man page for 
>> more information on that syntax and if you want to do more funny things:
>> http://dar.linux.free.fr/doc/man/dar.html#CONDITIONAL%20SYNTAX
>>
>> Cheers,
>> Denis
>>
>>
>> Le 22/12/2025 à 20:30, ogreg--- via Dar-support a écrit :
>>> Isolating the catalog from an encrypted archive:
>>>
>>> /dar -zzstd -N -B lennz-darrc -R /proc/cygdrive -C /proc/cygdrive/F/ 
>>> darback/lennz-1-C-0 -A /proc/cygdrive/F/darback/lennz-1-F-0/
>>> Archive lennz-1-F-0 requires a password:
>>>
>>> lennz-darrc contains the line:
>>> *-K aes:secret*
>>>
>>> The previous steps dar -c, dar -t, and dar -d run with a similar 
>>> command line, but are able to used the needed information from lennz- 
>>> darrc.
>>>
>>>
>>>
>>
>>
> 
> 

Re: [Dar-support] mail archive download

[Denis C. <dar...@fr...>]

Le 25/12/2025 à 00:20, aardric via Dar-support a écrit :
> Hail,

Hi,

> 
>       Is there a downloadable archive of all forum messages in some
> common format (mbox for example)? The forum contains much useful
> information but searching is so much easier within a local mail reader.

this mailing-list is a service provided/hosted by sourceforge.net and 
rechecking the mailing-list parameters, I could not find any option to 
expose the mailing-list content to another format. Though the history of 
all information is archived since year 2003 at sourceforge and 
accessible through the web interface you have probably found...

I have no better answer.


> 
> 
> Rick
> 
> 
> 
> 

Cheers,
Denis

[Dar-support] mail archive download

[aardric <aa...@aa...>]

Hail,

     Is there a downloadable archive of all forum messages in some 
common format (mbox for example)? The forum contains much useful 
information but searching is so much easier within a local mail reader.


Rick