Re: unchanged files backed up multiple times

Hi all,

Am 13.12.2024 um 06:28 schrieb Marcin Haba:
...
> Your notice about too long mtime is fully right. It is because the
> lstat string is broken. Two lstat values are joined together and it
> causes this wrong result. If we split them, then the decoded values
> are more realistic and the number of single values is correct in
> lstat:

I wonder how we can end up with such lstat data. There must be a reason, 
and I'm quite sure I have never seen such a situation (which doesn't 
prove anything). The fact that the encoded time stamps are out of bounds 
for most current libc implementations, but the time stamp comparison 
obviously worked, just incorrectly, will at least avoid problems due to 
files not being backed up.

Can you check if similar situations exist using a catalog query such as

select jobid,length(lstat),lstat from file where length(lstat)>59;

so we can see if this is a problem happening more often? It's going to 
be a long running query as it'll cause a full table scan, I think... at 
least here I have it running for a few minutes now.

Sanity checking I tried here:

$ date -d @6952011706864740382
date: time ‘6952011706864740382’ is out of range

One thing that might be interesting could be to see if you can identify 
files the two concatenated lstats actually belong to. Perhaps we can 
find a non-obvious pattern.

Cheers,

Arno

-- 
Arno Lehmann

IT-Service Lehmann
Sandstr. 6, 49080 Osnabrück



_______________________________________________
Bacula-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bacula-users