Unexpected error message for missing target folder

Support
1

[using 2.0.7.1_beta_2023-05-25]
I configured a job to backup parts of the D:\ drive from my Win11 laptop to a network drive X:\ (a local Synology NAS).
Obviously when I boot up the laptop while offline the job will fail to run.
Until lately this resulted in 5 fruitless attempts and a final error message (with pop-up):

The folder X:\Duplicati\ doesn’t exist.
System.IO.IOException: Network path not found.

– which was OK and explained it well.
Recently instead I get a pop up in this case:

Found 62 files that are missing from the remote storage, please run repair

For full log files see attachment
log files.zip (3.4 KB)
It starts off with the same “attempt 1 of 5” but then goes off and actually tries to perform the backup.
BTW the number of files "“missing” exactly matches the total number of files at the target location on X:.
In the beginning I was confused and ran repair a number of times, until I realized, that as soon as I was connected, the job ran as usual. So, much ado about nothing.
I don’t remember having updated Duplicati lately.

Does anyone have an explanation why Duplicati now behaves differently?
Is there a way to restore the previous behavior, reporting just a missing network path?

2

because the list sort of worked, meaning Windows didn’t return an error to the request then:

2024-02-24 19:55:29 +01 - [Information-Duplicati.Library.Main.BasicResults-BackendEvent]: Backend event: List - Completed: ()

Does the unwanted list success happen in such a clearer case? What does dir command say? Alternatively, when Duplicati says it can list the empty folder, does anything else see one too?
Maybe some sequence of operations such as connecting for use, then going offline causes this.

3

Thanks for pointing me into the right direction:
Some folders on my network drive X:\ are synchronized with the NAS via Windows Offline files.
The folders ‘X:\L15 Win11’ and ‘X:\L15 Win11\Duplicati’ have an availability status of “available”, however the files inside the Duplicati folder are “only online” available. So you can actually run
dir 'X:\L15 Win11\Duplicati'
but it returns 0 files. This would explain why the list command “sort of worked”.
Odd however is, that the log file starts off with a “folder doesn’t exist” message, but then in retrying goes off and get the list done anyway.
In short: I need to make up my mind if I want to have 'X:\L15 Win11\Duplicati' synchronized in full (including files) or not at all.
What I haven’t found out yet is, however, how to reset a folder into “online only” availability status after it had once been “offline available” (even after deleting offline copies). So far I didn’t get closer than “available” - which means a dir will still work there. So I guess I will have to live with the “missing files” until I find a solution.

4

might have some ideas.

5

thanks for the link, but this seems to refer only for sync to OneDrive. At least I don’t get any reasonable information with the attrib command on my folders (being available offline or not).

6

I think the logic with folders being “online only” is not something that is really supported by the backend.
When you use the file:// backend, it expects a regular filesystem with somewhat POSIX equivalent semantics.

Not sure how the “online only” is implemented, but I see similar issues with Dropbox, where listing the folders appears to work, but actually accessing the files causes weirdness.

I would say the best solution for future fixing is to detect the folder state. If we cannot toggle it, then give a sane error message.

For current fixes, I would suggest using any of the protocols that does not rely on the filesystem.

You can ignore missing source folders with --allow-missing-source, but you cannot ignore missing destinations, because then the backup will not run.

7

Thanks for testing. After trying to get documentation (this is Windows Vista era, and seems to be
fading away), I’m thinking that its available controls might not bear much similarity to OneDrive’s.

The Windows Drive Letter Problem has a possible solution to detect not-really-there destinations.

  --alternate-destination-marker (String): Look for a file in the destination
    folder
    This option only works when the --alternate-target-paths option is also
    specified. If there are alternate paths specified, this option indicates
    the name of a marker file that must be present in the folder. This can be
    used to handle situations where an external drive changes drive letter or
    mount point. By ensuring that a certain file exists, it is possible to
    prevent writing data to an unwanted external drive. The contents of the
    file are never examined, only file existence.

If that’s not sufficient, but there’s still some way to tell, you can write your own run-script-before.

8

Thanks for the suggestions and insights. For the time being I decided to make the destination folder avalable offline, so backups can run even when offline. Windows synchronization will then take care of synchronizing the local and remote folder when again online.The only glith that remains is then the warning - being offline - that the job can’t send a message to duplicati-monitoring. I can live with this one …