USN option working inconsistently

ts678 · February 19, 2020, 12:55pm

It’s not a hard failure that will cause --usn-policy=required to error. There are a few soft failures that can cause full scans to happen. You can see them in the log at Information level. An example of such log is:

2020-02-19 06:38:16 -05 - [Information-Duplicati.Library.Main.Operation.BackupHandler-SkipUsnForVolume]: Performing full scan for volume "C:"

and possibly this case is:

github.com

duplicati/duplicati/blob/082a14fc22efdef226c1bee956f85009f7104fb3/Duplicati/Library/Snapshots/UsnJournalService.cs#L67-L68


      
          if (prevJournalData == null)

              throw new UsnJournalSoftFailureException();

Then the question someone can look at is how it managed to stay empty despite post-backup work at:

github.com

duplicati/duplicati/blob/082a14fc22efdef226c1bee956f85009f7104fb3/Duplicati/Library/Main/Operation/BackupHandler.cs#L233-L245


      
          // store journal data in database, unless job is being canceled

          if (!token.IsCancellationRequested)

          {

              var data = journalService.VolumeDataList.Where(p => p.JournalData != null).Select(p => p.JournalData).ToList();

              if (data.Any())

              {

                  // always record change journal data for current fileset (entry may be dropped later if nothing is uploaded)

                  await database.CreateChangeJournalDataAsync(data);

          

                  // update the previous fileset's change journal entry to resume at this point in case nothing was backed up

                  await database.UpdateChangeJournalDataAsync(data, lastfilesetid);

              }

          }

I’d like to find a way to tie this into your P.S. issue on repeating opens, but I can’t explain 30% reopens:

Duplicati detects spurious timestamp changes