Protecting things from shells is always a challenge. GUI needs less help, but has its issues, e.g. here…
Thanks to @JimboJones for finding that old one. I tried 2.0.5.1 and 2.0.4.3, but they also didn’t decode.
One reason I tried is that sometimes things do change, e.g. here’s a change done in Sept 2020 in area:
A more recent fun one was a fix of “AllowEncodedSlashes On” for Apache (the reverse proxy?) to work.
I don’t know if the formal URI standards give enough guidance to change URI parsing, but we’d need to avoid breaking on URIs that are already used in backups. The concern was mentioned in the above PR.
@gpatel-fr I’m not sure what you’re trying to say, your example certainly works. If you try that sequence when there is a user named “mydir” on the system it won’t turn out the same way.
I am just warning people that “~” can have unexpected side effects in UNIX/Linux.
point is, the restrictions on ~username have nothing to do with Unix/Linux. This is a behaviour of special programs, shell. Most (not all) conform to the old Posix standard of aliasing ~username to the home directory of ‘username’. But this does not apply to all software, including Duplicati, and all the servers that can run under Linux or some other Unixy systems, that will accept such directory names without any problem.
Also file managers such as Dolphin (the Kde file manager) do not follow this Posix convention.
Even Bash will accept to handle them if one asks nicely:
(py311) gerard@j5005:~/Images$ mkdir '~root'
(py311) gerard@j5005:~/Images$ cd ~root
bash: cd: /root: Permission non accordée
(py311) gerard@j5005:~/Images$ cd '~root'
(py311) gerard@j5005:~/Images/~root$ pwd
/home/gerard/Images/~root