>>>>> On Fri, 13 Dec 2024 10:23:18 +0100, Arno Lehmann via Bacula-users said: > > 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.
My guess is that the lstat is just corrupted in the email (and is probably correct in the catalog). Notice the line starting with +----... has no + at the end, so it doesn't match the format printed by sql query. > 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? I have many lstat entries longer than 59 because the st_dev is large. __Martin _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
