Comment 12 for bug 1549776

Thanks for your feedback Vej. I'll examine this ASAP.

> - Compile

Did you install the executables afterward, or did you test in the test shell? In case you installed the executables, can you please explain how you did it? I couldn't find out how.

> - Add the folder to your include list

Using the GUI?

> - It will be presented as ~/Music/ggfgh (or what ever
> localized music folder you have) in the GUI.

GUI that you opened with the command deja-dup-preferences in the test shell?

> - Change the entry inside of the gsettings value from
> /home/test/Music/ggfgh to $MUSIC/ggfgh
> - Open the GUI again and look at the "Folders to save"
>
> What happens: The folder is presented as /ggfgh.
> What I expect to happen: The folder should be presented
> as ~/Music/ggfgh.

If you used the test shell, that might be "normal": I noticed that when testing things in the test shell, using the current revision 1570 (my patch has nothing to do with it), neither the trash nor the user's special directories are found, i.e.

  Environment.get_user_special_dir(UserDirectory.MUSIC)

returns an empty string, while

  Environment.get_home_dir()

returns /home/<user> as expected. So when using the test shell, $MUSIC/ggfgh would become /ggfgh indeed, and I suppose it would become /ggfgh whether or not you previously added ~/Music/ggfgh in the GUI or not.

See the remarks at the end of the file I joined to comment 8. If you did use the test shell, you can probably reproduce the behavior you mention in comment 11 by using the current, unpatched code at revision 1570.

If this non-support of special directories is indeed, as I understand it, a bug in the test shell, and if it is not beyond my abilities, I would be happy to try and fix it.