Re: [Dar-support] dar diff that detects missing and added files

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

Le 28/11/2025 à 15:52, John Goerzen via Dar-support a écrit :
> Hi,

Hi John,

> 
> I'm looking into how to verify that a filesystem matches the original
> source material, especially when the target is the result of applying
> differential atop differential maybe every day for years.
> 
> Previously I had been using mtree to do this, but it occurred to me that
> the dar catalog for each differential actually captures the full state
> of the filesystem.
> 
> I noticed that dar --diff will notice if a file present in the catalog
> is missing from the filesystem, but will not notice if there is a file
> in the filesystem that was missing from the archive.

I've double checked and you are right, I will see how to fix that.

> 
> The notes hinted at doing a differential in dry-run mode, but even when
> run with -v, it gives the opposite: files that were added to the
> filesystem but not ones that were omitted.
> 
> It would be great if --diff could notice both.
> 
> I've found a workaround in:
> 
> dar -v -c - --on-fly-isolate diff --ref t2 -R directory > /dev/null
> 
> Then I can do:
> 
> dar -as -l diff
> 
> which is approximately what I'm after.  This has the inefficiency that
> it will try to read every modified file, which is strictly unnecessary
> for this operation, but does seem to work.

Yes that's correct. Note also that the dry-run method also reads the 
data as if it was performing a normal backup, this is only the latest 
stage (the lower archive layer) that is replaced by a "null_file" object 
instead of a plain file (fichier object). So your approach is not worth 
than the dry-run differential backup assuming I fix the lack of display 
about the files recorded as removed since the backup of reference was done.

> 
> Is there a better way to do this?
Today at short term/current release, I do not see a better solution.


>  Could diff be enhanced to do it?
I will have a look at how to enhance that, but this is more complicated 
because actually the process is to scan the catalog for each entry it 
has and check whether there is a corresponding entry in the filesystem.

To detect newly added files, libdar would have to scan the other way: 
check each entry present in the filesystem and compare them to what's 
available in the catalog (which then do not see removed files).

Well, there should be possible to leverage some directory caching used 
in libdar and perform this reverse at the end of each directory scanning 
to avoid reading again the metadata from the filesystem... this is to be 
confirmed and will take place if possible in next major release (2.9.0).

> 
> Thanks!
> 
> John
> 

Cheers,
Denis