The behavior here on Windows 10 and Duplicati 188.8.131.52 is that it notices Explorer rename too –
if the backup gets to the file by having its containing folder configured. Direct config doesn’t notice.
I have a folder tree in my backup configiration, and the files in question are located deep in sub-sub directories.
This is interesting, because the case insensitivity of NTFS and the system level commands for file manipulation sould be normal Windows behaviour, since ever, and I nearly accepted to live with it. This is at least my conclusion from reading this:
You did’nt apply “fsutil.exe file setCaseSensitiveInfo enable” to your root folder, which is explained in this article, did you? Maybe a long time ago?
Just a guess. What else could explain the different behavour of our installations?
Now what has been tried by @ts678 and myself is running a test backup on a given directory and changing a file under this directory. It worked. Then after your first reply I think everyone assumed that the problem was when selecting a file direct from Duplicati (a corner case if there is one, absolutely not worth the effort to fix). And then you seem to imply the reverse, that a file changed under a directory included in Duplicati don’t trigger a backup. I don’t get it. What’s the deal with WSL ? you are not doing some mixing up Linux and Windows by any chance ? If yes, that’s a very significant detail that you forgot to mention in your initial post.
Can you create a test backup with one directory and one file under it, no WSL, and post the results of doing a backup, preferably by exporting the job as command line and run it from a terminal window, add
to the command and just post the output, not the actual command line if you prefer to keep the connection details to yourself.
This setting controls the usage of NTFS USN numbers, which allows Duplicati to obtain a list of files and folders much faster.
and for me, using USN results in a failure to notice rename even if a containing folder is configured.
Possibly other configuration differences exist, so either start simple then get complex, or vice versa.
Thanks for the reply. No I never touched all-versions options. BTW, the fact that after picking a version (the first one in your case), Duplicati could display all versions should be considered a bug by itself. But I’m not sure that it is the case.
Anyway, what I did on a vanilla backup without any options (except picking a backend), was to rename a file in different ways with USN on. After my tests and seeing the display problems I have cited, I turned USN off and did a backup again. Here is the result for restoring the version 0:
and preceding version:
I did not change anything between the 2 screenshots, only selecting a different version.
Needless to say, the real situation on disk is in both cases the one displayed in version 0 (created without USN)