Git Rev.: e22a2467c80e2b541e5debff76f84d9d70ce057d Creating a new album fails due to an invalid pathname. For example, I have an album root at /var/media/photos. There is an existing Album at /var/media/photos/imports. When I try and create an Album "2016-08-05" as a child of imports, I get an error message: Failed to create directory 'file:///imports/2016-08-05'. That is to say, digikam is attempting to create /imports/2016-08-05 when it should be trying to create /var/media/photos/imports/2016-08-05, and failing because /imports doesn't exist. This also affects creating new albums at import time. Browsing existing Albums seems to work fine. Reproducible: Always Steps to Reproduce: 1.Select an existing album (or root) 2.Use Album->New 3.Use the "Child of: Selected Album" option, click OK. Actual Results: An error message such as Failed to create directory 'file:///New Album' Expected Results: A new album to be created. Using strace confirms that the wrong path is sent to the operating system: mkdir("/imports/2016-08-05", 0777) = -1 ENOENT (No such file or directory).
Created attachment 100470 [details] Screenshot after creating album This issue is not at all reproducible. Creating an album works perfectly fine. I followed exactly the same you mentioned and album is created successfully. I had an existing album at home/Pictures/Test Album and I have created a child of Test Album at home/Pictures/Test Album/2016-08-05 successfully. Did you use MySQL or SQLite? I recommend to try again with fresh DB.
The same here, is not to reproduced. If "/var/media/photos" an external removable drive? Maik
Can I close this file?
It is MySQL. /var/media/photos is on a NFS drive.
I noticed the path in AlbumRoots is %2Fvar%2Fmedia%2Fphotos. Changing this in the database to /var/media/photos and restarting digikam fixes the problem. The %2F it must have been created by a previous versions of digikam, so I think this is still an issue but it is an upgrade issue rather than an AlbumsView issue.
The problem with the encoding path is already reported to bug #365313 *** This bug has been marked as a duplicate of bug 365313 ***
Not reproducible with 6.1.0 Gilles Caulier