I saw it, found code, thought avoiding that message would need hacking on paths in the database, and didn’t think that was a thing you’d want to get into, or that I could help with. I also considered noting that material could be reused if you (or someone someday) could craft code to convert and repackage it all. The data blocks of the file contents should be OS-independent – but that’s not all that’s in the backup…
Again, when you say “only way”, it’s up to you to decide how ambitious you want to be in finding another.
I suggested multiple unproven ways to avoid that by continuing to use a Linux environment on Windows, however you have found another unproven idea involving hacking your database by hacking backup files then using them to recreate the database. This seems slightly more appealing than direct hacking of DB although we never heard if it worked, and I still wonder what happens to the Windows metadata stored in remote files. You might have some info about that from what happened on your surprising cross-platform restore. If it somehow was able to get a creation and modification time onto Windows, that’s a good sign.
I’m not sure I fully follow the “Changing source OS” steps, e.g. what is done with current dlists that aren’t the dummy? If you recreate the database, it will need the dlists to restore that version, meaning they may all need to get hacked. If you can persuade Duplicati to pull in all of the dblocks then not compact data as unreferenced source blocks (maybe set –no-auto-compact, just in case), then the next backup might put them to use again if they are still relevant, i.e. useful as a block in one of the current files being backed up. This would avoid reuploading all the data for the current version. Old versions could use Linux, if need be. Allowing or forcing compact would probably trim your remote space usage whenever you’re ready to do it.
Seeing the lead author suggest this raises confidence it probably works at least in part, but I can’t detail it.
EDIT: If you conclude mass dlist editing is needed (I don’t know) to convert your old dlist files to Windows, and if you don’t want to use the Python or other code-heavy method, and because of the mentioned issue with forward slashes being present in hashes, a possible alternative might be edits by regular expression. RE syntax varies, but if you use vim for the dlist edit, it’s said to be similar to Perl, so I think that’s enough.
How to escape special characters in building a JSON string? shows special cases it might need to handle including the most guaranteed-relevant case which is that Linux forward slash becomes two backslashes on Windows. If it’s already encoded as the backslash and forward slash, then that becomes the backslash backslash. You can look. You probably would also add your Windows drive letter in front of path. The main goal of the regular expression is to ensure context, e.g. verifying "path": in front of the string being edited. This isn’t the “proper” way to deal with JSON, but if the proper way is too hard, it might give you enough…