I decoded the correct lstat values using bconsole and compared them. It appears that only ctime and atime are different. The ctime for the file changed in november. I must have done a chmod or something that changed file metadata.
Given the small number of impacted files, and the fact that permissions for these folders should certainly be determined by the root folder, what can I do to prevent bacula from considering a ctime change to be a reason to back the file up again? I assume (perhaps incorrectly) that bacula isn't selecting files based on changes in atime. In any case I will implement noatime / nodiratime in my mounts, as suggested. I am apparently bad at going to bed. ;) Regards, Robert Gerber 402-237-8692 r...@craeon.net On Fri, Dec 13, 2024 at 6:26 AM Arno Lehmann via Bacula-users < bacula-users@lists.sourceforge.net> wrote: > Hi Rob, all, > > Am 13.12.2024 um 13:02 schrieb Rob Gerber: > > Everyone, > > Thank you very much for all the help with this interesting problem and > > for your advice. > > > > Arno, > > that query very quickly returned 443123 lines. Looking through them, > > some were longer than others. > > Indeed. the 59 characters was not well considered. Depending on length > of the fields you can have considerable variations. Here, 70 bytes was a > useful length to list, and of course if we look for doubled strings, > something larger than 110 would be a good indication of problems. > > ... > > I happened to read your email when I briefly woke up, so I'm going to > > bed again now. > > Enjoy ;-) > > 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 >
_______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
