Yes, that did it! Thanks.
@manu: Big thank you, you saved my day.
My thanks also. You folks made it easy for me!
Thank you, repaired here.
Are there any reasons why this would fail due to having ++ in the path?
I am trying to upgrade a Windows 10 Pro based, non-Service, install to the newer beta.
It was using OneDrive v1 and the previous beta. Now I am trying to swap to OneDrive v2.
I have swapped to v2 in the GUI as above thread notes, hit CTRL+f5, changed the authid, also used different browser to check the backup folder really is still there…
But I get this error message instead. The path is supposed to be ++BACKUPS/Test and this is an Office365 account for a “home” user.
Notice how in that screenshot there are no ++ on the path?
As a test, I swapped the path to just BANANA and then let it create the folder when the test button asked. And sure enough - there is the new folder in OneDrive.
So, whilst not even leaving the page, I now change the path to zzBACKUPS/Test and use the other browser to rename the folder on the server.
Sure enough, we now have success. Backup running - picked up from the old files. And all is continuing.
POSSIBLE ISSUE: Why did the ++ in my OneDrive path make it fail?
Duplicati.CommandLine.BackendTool.exe let me try out variations (and see errors) a bit more easily, and the suspect wound up being Percent-encoding in a URI which I’m not sure is being done correctly. You can follow that chart, converting a plus sign to the sequence
%2B to see if it lets plus work. That’s a workaround, not a fix. For a code fix (if manual encoding actually helps), please file an issue to get the fix request queued.
This same issue possibly explains this problem found by @thepappaq where workaround was to do a folder rename. That one was a little murkier because the
# (number sign or pound sign) is also an invalid character sometimes, so Microsoft Graph’s unifying things could maybe have unified restrictions, but plus is not invalid:
Thanks for testing out variations of names. If you would like, feel free to try other characters that should also be percent-encoded. The test data for the URL encoding theory so far is a little thin now, but could be better.
To add a little bit to this test. This was a live setup of three computers. Each sending a selection of files into the same OneDrive account. The path had the ++ signs in it when running a backup using the older OneDrive V1 as a destination. That had been running happy for a while. So this issue has crept in as part of the migration to OneDriveV2
To fix it, all I needed to do was rename the folder on the server to remove the ++ and update the path in Duplicati. All was then very happy and the backups have picked up and continued.
I apologise that I don’t have time to keep up with all the life on the forum, so get a bit lost in the technical details at times here. I also don’t have a GitHub account, but hope these very repeatable findings are of use.
What is especially key here is the error message is clearly showing the ++ missing from the path. So that is an easy tip for other people to spot if the issue is the same for them.
I’m curious to hear if people have the same issue if the “+” is in the middle or end of the folder name. (I suspect they will.)
When I work on the machine again this evening I’ll try a few other random path tests.
It is simple to test when just setting up a new backup destination. If I put in a path it doesn’t like - it will error if the path exists or not. So I’ll try a few other combos out. FOL++DER, FOLDER++, FOL!!DER and FOL DER also FOL%2b%2bDER to see if the percent encoding works.
Anything else you would like me to check?
It is certainly a downgrade from previous. The path was happy before as these are legal characters for a file path. Simple to guess the fix though thanks to the verbose error splurge. I may not have understood what any of it meant, but I could see my path had spaces instead of ++ signs.
I’m actually in the middle of upgrades on two different Office 365 systems. One is Office365 Home and the other is Office 365 Business. Both happily using OneDriveV2 now.
(I have to say it is a little confusing trying to pick the correct choice with three different OneDrive options, and two different SharePoint choices. That had me running round in circles for a while due to lack of example paths.)
Windows 10 Pro 1809 PC. Current BETA release. Office 365 HOME account. Chrome browser.
Press ADD backup, give it any name and password, hit next.
Set Storage Type to OneDriveV2, setup AuthID (using Office 365 Home account)
Now put test path into the Path on Server box and hit TEST.
- An accepted path will offer to be created. (Press NO as folder not needed)
- A failed path will kick out the error box as in my earlier post.
(Note I never proceed past this Backup Destination setup page. I just backed out of the half setup config once testing is completed. The [Test Connection] button was all I needed for the path test)
All of the following are legal paths. Plus, Space, Exclamation Marks are all legal for folder names. (And used to work with OneDriveV1)
The error message said “contains invalid trailing character” when the ++ were on the end of the folder name.
The error message also said “contains invalid trailing character” when the ++ were on the start of the folder name.
That does go to imply that the issue only occurs when the “invalid characters” [sic] are at the start or end of the folder name. Perfectly acceptable in the middle of a foldername
Using Percentage Encoding
The use of percent encoding DOES work.
zzBACKUPS/%2b%2bFOLDER did create zzBACKUPS/++FOLDER
zzBACKUPS/FOL%2b%2bDER did create zzBACKUPS/FOL++DER
Other feedback from a noob to this backup
The error messages are SERIOUSLY impossible to read for us mere humans. Any plans to have clearer error messages with the developer info hidden behind an advance button?
Only now when I am reading it after testing have I actually see the text at the end there about “contains invalid trailing character”. it would be REALLY helpful if text like that was highlighted in some way. Or promoted to be the first line.
Or maybe the errors just need a “Translate for ID-10T user” button.
Also a LOUD tip here when testing Office 365 Accounts - USE PRIVACY MODE
I notice in the forum discussions the authentication can get confused. Web browser remembering login details. Or remembering details of a different account. Or different user.
If you are getting problems then open your web browser in INCOGNITO MODE or PRIVACY MODE.
Usually done by a RIGHT CLICK on the icon and launch the browser. Now when you sign in you are certain to not have any old credentials around.
When testing I’ll often have multiple instances of the browser running like this, allowing me to be connected to multiple different Microsoft accounts with out clashing.
Same trick works with Google Accounts and no doubt most of the cloudy stuff.
Thanks for all the testing and browser hints @BatterPudding!
I’m a little confused as to why the ++ NOT on the ends work as I was assuming the issue was that + (being a normal replacement for a SPACE in a URL) was NOT being encoded on the way out but the recipient of the path assumed it WAS encoded so converted the + to SPACE (then likely trimmed them off the ends).
But ignoring my confusion, it sounds like for now the %2b pre-escaped characters seem to be a viable (though annoying) workaround.
Other commonly URL escaped characters would include:
Thanks for your browser tips! One drawback of most private/incognito modes is that they are usually the same across all windows. So even if you have 2 Chrome Incognito windows open, they’ll actually share cookies and the like.
I get around that by using Chrome profiles as they each have their own set of cookies. If I only need 2 distinct Incognito windows I open a “Guest mode” window (which is a separate profile, incognito-like by default) along with my normal Incognito window.
For anything more than that I create additional profiles (it’s not as hard as it sounds!) and open each of those in an Incognito state.
Haha - yeah, that was the first finding I knew would make you puzzle.
Don’t forget - this all worked fine with ++ signs in OneDriveV1 so I doubt “plus replacing space in a URL” is the issue here.
I hope you spotted in that test was also a SPACE in the folder names. Again acting in a similar way - failing when on the start or end of the folder name, but fine in the middle of the folder name.
I’ve also used your Escaped Characters list to adda few more successful test to the above list. Really looks like this is only + and SPACE causing problems.
The list of Escaped Characters you have popped up there includes various illegal file characters in the NTFS \ OneDrive file systems. I know OneDrive bans a few extra characters that would be legal in NTFS. (For example, the # used to be illegal in OneDrive for Business \ Sharepoint. Not sure if that is fixed now. I remember it used to be a migration “gotcha” if swapping between the 2015 era Home and Business OneDrives.)
For the curious:
So that makes the “illegal” list just. The old restrictions have gone. Which is good
" * : < > ? / \ |
With the Privacy Modes and Google Chrome sharing cookies… Probably why they call it “incognito” as nothing is “private” in Google’s world.
On my own PC I have about eight different browsers installed - none of them Chrome. So I have plenty of options for multiple sessions with and without privacy mode running.
Thanks for that additional testing. One thing that’s kind of special about a plus and space is that sometimes they translate into each other. I’m not an expert on encoding rules, and this one seems a special case. See:
I was previously trying to look over Duplicati’s encoding. Now switching to a look at decoding, I’m seeing this:
Maybe that’s where plus becomes a space, and possibly spaces are allowed in name middles, but not ends. Basically there’s probably a bug in here, but someone will have to debug it more than a support post allows.
It is hard to understand a couple of lines of code outside of normal context, but if there is a line in there swapping + to SPACE then that is a nasty sounding bug. I often use + in folder and file names as a trick to sort it to the top of the list.
If you have access to the code diffs then is this a section that has changed between OneDriveV1 and OneDriveV2? Those ++ signs were fine in OneDriveV1
Edited to add:
Did you read those “URLs and plus signs” links you pasted? Both of them are quite clear that you are not supposed to use + signs instead of spaces in URLs. Maybe in the arguments of the command \ query after the ? but never in the path of the URL.
They are certainly not interchangeable characters in file paths or OneDrive.
You’ve confused me again…
I wasn’t involved, or following development, but I think OneDrive v2 came in new code from pull request:
Add new backends for OneDrive + OneDrive for Business, SharePoint, and Microsoft Groups based on the Microsoft Graph API #3118
and with file diff which seems primarily new code. Green is added, red is deleted. UrlDecode is in green.
More meaningful would be to see if the old code had this. Code going back to 2014 is here and doesn’t, though code can sometimes be in multiple files, or done in multiple ways. I still suggest you file an issue, although if you really don’t want to do so, perhaps I could file one for you and refer back to this article…
The plus signs that got in the URL are yours, but they’re legitimate, and meant as plus signs not spaces.
I suggest an expert in this figure out encoding. The accepted answer in the second link suggested doing percent-encoding of space as %20 and plus as %2B. This discussion should continue with development.
Best practices for turning support requests in the forum into issues in GitHub haven’t been stated AFAIK, however above is an example of the flow to get code change in GitHub. Often it begins with GitHub issue, someone picks it up, figures it out, writes code, makes a pull request, and eventually we all have the fix…
@ts678 again, you’ve lost me. I don’t do GitHub or have any idea how to report issues on there. I haven’t a clue about the source code. There is no point me trying to read it. I can’t fix the bug and you’d not want me working on your code.
I am trying to give some feedback via the forum. I thought some of my experiences may help.
Mainly I was trying to highlight the before and after differences experienced, but it looks like I have just caused more confusion to you.
Sorry if this was covered, but do I recall was testing being done with command line? If so, that might help isolate whether or not it’s a UI encoding issue.
Also, do we know if this has been tested with other destinations? That might help isolate where in the code the problem is.
Usually when creating a ticket (which I can take care of) it’s best to include a “how to reproduce this yourself” steps and offering steps that work with more than one destination are more likely to attract developers.
I’m not a tester or a developer. I am a user. I’m just using the product to backup half a dozen small home user setups. Never more than two or three people. This example was dealing with Windows 10 PCs to OneDrive Home and OneDrive business. Always using the GUI.
I was working at two unrelated sites. One user Home the other Business. I was trying to bring my findings into a simple summary here.
The example above I did try and give repeatable steps. But I think something has been lost in translation. Sorry to confuse things.
No problem - there wouldn’t be much point in developing if there weren’t any users!
I was just checking to see if something had already been done so it wasn’t repeated. I’ll work on the tests I described and get a ticket submitted. Thanks!