Version: 0.9.3 (using KDE 3.5.9) Installed from: Debian testing/unstable Packages I had an album named 'Sortownia' (polish for a place for sorting). Then I've changed the name to '#Sortownia' (to alter the sorting). That didn't help so I've changed the name to to 'ZSortownia'. This caused the album to dissapear along with the directory and all files in it (yes, data loss)! I've recreated the 'Sortownia' directory, whitch showed the missing files, but they were unaccesible. I've tried to touch one of them but that showed only that the touched file exists with 0 lenght (cache? don't know really).
Hi Michał, I can reproduce the problem! Very weird.... Actually, it turned out that the ZSortownia was moved (one level up) into my homedirectory.... Hopefully your images are there as well. .... (And hopefully you have a backup ...) No idea about what is going on. This is a critical issue, so I set the priority to VHI. Arnd
Yes, the files where there intact. Thanks.
Marcel, Any ideas where is the problem ? Gilles Cauier
It only happens, when one uses # as first letter of the directory (=album name). Maybe there is not enough quoting done, when doing the rename? (The only message I see is "kio_digikamalbums: Deleted Album: /ZDCBSortownia") Additional remark: that the sort order of the album is not updated is a separate issue. Michal: if you click one the "My Albums", the order of display is reversed. Doing this twice should trigger a correctly ordered view. (Note: sounds like a missing update somewhere ....)
Reversing the sort order back an forth didin't help. But the same issue exists for sorting with #'s in Konqueror (can't say KDE in general, as I didn't explore the problem much). In addition if I've tried to delete an album named '#Test' in the confirmation window I see '/#Test'. But the ablum is deleted propperly along with the directory.
Remember that in web URLs, the '#' denotes an anchor in the page. This means KUrl will strip these parts away if not properly escaped. We must look for places where escaping can fail (because the file name is created by QString::operator+? Because a URL is not recognized as a path? Using addDirectory()?)
I got the culprit: bool AlbumManager::renamePAlbum Here KURL u = KURL(album->folderPath()).upURL(); u.addPath(newName); u.cleanPath(); is used. This gives for a rename of /#AZZASortownia to AZZASortownia for u.path(-1) as result /home/username/AZZASortownia. I.e., for /home/username/Pictures/#AZZASortownia, the #... is stripped, the upURL gives /home/username/ and therefore /home/username/AZZASortownia which is outside of digikams tree ... ;-). So how to solve this? Could QDir and QDir::cdUp () be useful?
We need to try out... If you look at the docs then the # character is used there as the example where things can go wrong ;-) album->folderPath() is a QString; does the constructed KURL take it as a path, that is, is the # in KURL(album->folderPath()).url() properly escaped as %23? Then it's a bug in upURL().
SVN commit 795158 by abaecker: By using KURL::fromPathOrURL instead of just KURL to construct the path when moving a directory proper escaping of # is ensured. CCBUGS: 160323 TODO:KDE4PORT M +2 -1 NEWS M +1 -1 digikam/albummanager.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=795158
Michał, I think the committed patch solves the problem. Dould you maybe test the current implemementation from svn? Many thanks in advance, Arnd
Arnd, Tested here. All work fine now. Thanks. Note KDE4 no need to be fixed. Code is different now and i cannot reproduce the bug: ... QString oldAlbumPath = album->albumPath(); KUrl u = album->fileUrl(); u = u.upUrl(); u.addPath(newName); if (::rename(QFile::encodeName(album->folderPath()), QFile::encodeName(u.path(KUrl::RemoveTrailingSlash))) != 0) ... Like you can see, the album path can be get using fileUrl() witch provide directly KUrl container from DB witch take a care about his problem. Marcel, can you confirm than KDE4 is never affected ? Gilles Caulier
Yesterday I quickly looked at the code (which is really completely different) and found it all right; if you did a test and cannot reproduce the problem, we can assume it does not apply to KDE4.
Thanks Marcel. I close this file now... Gilles Caulier