Bug 224706

One other user on the digikam-users list confirmed the behaviour.

The renaming uses KDELibs::KIO::rename, maybe the problem is related to this under windows. 

Patrick, your viewpoint ?

Gilles Caulier

pshute,

It still reproducible with 2.x serie for windows provided by Ananta ?

Gilles Caulier

Sorry, I stopped using digiKam soon after I reported this bug.

Yes, it's still reproducible at digiKam 2.3.0 (using KDE 4.7.2).

The move-operation shows the same problem. When trying to move an album that contains an album, you get an error ("access denied ..."). Is it possible that this problem has the same origin?

Something new here?
I think it is an important function. Of course, you can rename and move albums with other tools (like Windows Explorer). But then you will lose all tags etc. of the pictures.

(In reply to comment #7)
> Something new here?
> I think it is an important function. Of course, you can rename and move
> albums with other tools (like Windows Explorer). But then you will lose all
> tags etc. of the pictures.

I can reproduce this. I'll try to fix it for 3.3.0 (or 3.2.0 if the problem is obvious in Windows)

Oh, wrong mail address...
My educated guess is that the rename function fails because a file handle is exclusively opened on/in that folder. To check if that is the case:
Please make a test album (with a subalbum), and just before you would really rename the album in digikam, try to rename it in the windows explorer. If this works in explorer, there might be different reason, if it doesn't work in explorer then we are looking for any occurance of an open file handle.
Gilles: do you have any idea where a file handle on the folder or a file in the folder is kept open all the time?

Hi Patrick,

Renaming an album from AlbumGUI context menu, is handled in background by AlbumManager::renamePAlbum() :

https://projects.kde.org/projects/extragear/graphics/digikam/repository/revisions/master/entry/digikam/album/albummanager.cpp#L2117

As you can see, KIO API is called here.

You must know that internally, digiKam as a class named DIO which is a low level file management interface to synchronized files manipulation and database. This will manage also XMP sidecar accordingly with setup.

https://projects.kde.org/projects/extragear/graphics/digikam/repository/revisions/master/entry/digikam/database/dio.cpp

Best

Gilles

I created an album with windows explorer while digikam was running.
I renamed it with windows explorer: no problem.
I created a sub-album and renamed the parent album again with windows explorer: it failed!

(In reply to comment #11)
> I created an album with windows explorer while digikam was running.
> I renamed it with windows explorer: no problem.
> I created a sub-album and renamed the parent album again with windows
> explorer: it failed!

Perhaps something to do with monitoring folders for changes. I'll test further in the next few days. Thanks for testing

(In reply to comment #12)
> Perhaps something to do with monitoring folders for changes. I'll test
> further in the next few days. Thanks for testing

The problem is even more general than previously described. As I suspected, this problem seems to be caused by handles created by KDirWatch (QFileSystemWatcher). Any folder with child folders will be unable to be renamed until the child folders are removed. It is not the handle created when watching changes on the parent folder that is causing the problems but rather the handle created when watching the child folders.

For example, here is the debug output for a child folder 'another' created under 'blah3':

digikam(3784)/kio (KDirWatch) void __thiscall KDirWatchPrivate::addEntry(class KDirWatch *,const class QString &,class KDirWatchPrivate::Entry *,bool,class QFlags<enum KDirWatch::WatchMode>): Added Dir "C:/Users/Ananta/Pictures/blah3/another" for "" ["KDirWatch-1"]
digikam(3784)/kio (KDirWatch) bool __thiscall KDirWatchPrivate::useQFSWatch(class KDirWatchPrivate::Entry *): fsWatcher->addPath "C:/Users/Ananta/Pictures/blah3/another"

'blah3' cannot be renamed until either the handle to 'another' is forcibly removed (crashing digiKam in most cases) or 'another' is deleted either in digiKam or Windows Explorer. Then 'blah3' can be renamed in either digiKam or Windows Explorer.

I am still trying to determine if there is a way around this besides not watching for any changes at all.

Ananta,

Any progress on this file ?

Gilles Caulier

(In reply to comment #14)
> Any progress on this file ?

Looks like KDirWatch (QFileSystemWatcher) will need to be rewritten to use something like ReadDirectoryChangesW instead of the old WaitForMultipleObjects. This was already started (and apparently abandoned for lack of time:

https://codereview.qt-project.org/#change,19274

Here are some references for future:

http://blog.rburchell.com/2012/01/qfilesystemwatcher-internals-in-qt-5.html
http://blog.rburchell.com/2012/03/qt-51-aka-when-qfilesystemwatcher-might.html
http://lists.qt-project.org/pipermail/development/2012-July/005279.html

Some options are:

1. implement our own ReadDirectoryChangesW monitor, like the inotify monitor we have for linux (perhaps based of the changes in the codereview link), until Qt supports it
2. add an option to digikam preferences to allow the user to enable/disable folder monitoring
3. disable folder monitoring on Windows except root folders
4. disable folder monitoring on Windows completely

I think 1 would be the best choice, but I'm not sure how long that would take and I have very little time at the moment, unfortunately.

-Ananta

Hi, Ananta,

Thanks for the feedback...

Why not to reassign this file to KDELibs/KDirWatch ?

Gilles Caulier

(In reply to comment #16)
> Why not to reassign this file to KDELibs/KDirWatch ?

Might be a good idea since it ultimately is their issue, although last I checked there was no one with time to work on it.

Since digiKam use pure Qt5 API to rename album, this problem is not reproducible.

Gilles Caulier