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
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
