[digiKam-users] Renaming a folder does not work

[karsten_df]

hi all,
when last using digikam, I ran into a problem I had not seen before.
I've imported some photos, creating a folder structure like
<year>/<month>/<date> automatically.
When trying to rename the folder afterwards from <date> to some
content-specific name, there's an error message popup window like 'cannot
rename folder'.
(The folder is then still renamed in digikam's view, but that's not my issue
here - the issue is, that it's not renamed at the actual storage location,
and the renaming therefore is reverted during the next scan for changes.)

Any ideas what could go wrong here? Should I create a bug ticket?
A permission issue seems like an obvious explanation, however how could the
image importer create the directories then?

I'm using digikam
- under (a rather fresh install of) OpenSUSE Tumbleweed, latest updates
(was using digikam before under Leap 42.2)
- with a mySQL data base on a separate server
- with images in multiple collections, most of which are on an NFS share on
that same server
  (the issue described is with a NFS collection)
 
Console output of a digikam startup (including search for new images) is
attached - I can't see any traces of the failed rename there. The error
should occur almost at the end of the console log
digikam_log.txt
<http://digikam.1695700.n4.nabble.com/file/t376440/digikam_log.txt>  

many thanks for your help -
Karsten

-------------------------------------------------------------

digiKam
Version 5.8.0
Build date: Feb 9 2018 (target: None)
KDE Frameworks 5.43.0
Qt 5.10.0 (built against 5.10.0)
The xcb windowing system

digikam version 5.8.0
CPU cores: 4
Eigen: 3.3.4
Exiv2: 0.26
Exiv2 can write to Jp2: Yes
Exiv2 can write to Jpeg: Yes
Exiv2 can write to Pgf: Yes
Exiv2 can write to Png: Yes
Exiv2 can write to Tiff: Yes
Exiv2 supports XMP metadata: Yes
KF5: 5.42.0
LensFun: 0.3.2-0
LibCImg: 130
LibJPEG: 80
LibJasper: 1.900.14
LibLCMS: 2090
LibLqr support: Yes
LibPGF: 7.15.32
LibPNG: 1.6.34
LibRaw: 0.18.6
LibTIFF: 4.0.9
Marble: 0.27.20
Parallelized demosaicing: Yes
Qt: 5.10.0
AkonadiContact support: Yes
Baloo support: Yes
Calendar support: yes
DBus support: Yes
Database backend: QMYSQL
Database internal server: No
HTML Gallery support: yes
Kipi-Plugins: 5.8.0
LibGphoto2: 2.5.16
LibKipi: 5.2.0
LibOpenCV: 3.3.1
LibQtAV: 1.12.0
Media player support: Yes
Panorama support: yes

digikam version 5.8.0
Images:
BMP: 4
JPG: 33194
ORF: 180
PNG: 13
RAW-CR2: 143
RAW-CRW: 740
RAW-DNG: 111
RAW-ORF: 7528
TIFF: 11
total: 41924
:
Videos:
AVI: 13
MOV: 24
total: 37
:
Total Items: 41961
Albums: 1033
Tags: 56
:
Database backend: QMYSQL
Host Name: ubuserv2
Host Port: 3306
User account: digikam
Connect options:
Core Db name: digikam_core
Thumbs Db name: digikam_thumbs
Face Db name: digikam_faces




--
Sent from: http://digikam.1695700.n4.nabble.com/digikam-users-f1735189.html

[karsten_df]

some more information, on what works and what does not -
(all using a mySql database on a server)

when working on a collection which is *hosted on the server via nfs share*:
- ok: creating a folder
- not ok: copying pictures (pictures are physically copied, but not shown in
digikam until re-scan)
- ok: remaning a picture
- not ok: renaming a folder ( folder not physically renamed, causes "Failed
to rename album" error,
                                        but new name is still shown in album
view)

Any ideas?
Karsten





--
Sent from: http://digikam.1695700.n4.nabble.com/digikam-users-f1735189.html

[woenx]

I tried renaming a folder, renaming a picture, and copying a picture into a
folder, and they all work just fine, and changes appear immediately in
digikam, with no error messages. I am using the windows version of digikam
(3.9 pre-release) and pictures are in a network share.

Are you sure you don't have a permission problem with these folders?



--
Sent from: http://digikam.1695700.n4.nabble.com/digikam-users-f1735189.html

[karsten_df]

As far as I can judge,  permissions are ok.
Actually, creating a folder should require the same permissions as renaming
a folder  (i.e. write to parent dir). The one works, the other not.
Something seems to be completely weird. Also behaviour for local collections
is different, but quite as erratic.
I've been using digikam for a while now, never had such problems. I guess
I'll completely re-install digikam - maybe my configuration is flawed..



--
Sent from: http://digikam.1695700.n4.nabble.com/digikam-users-f1735189.html

[Maik Qualmann]

If you renamed an album, it would be the correct error message "Failed to
rename Album". Can you please upload a image of the error message?

Maik

Am Freitag, 9. März 2018, 23:26:23 CET schrieb karsten_df:

> As far as I can judge,  permissions are ok.
> Actually, creating a folder should require the same permissions as renaming
> a folder  (i.e. write to parent dir). The one works, the other not.
> Something seems to be completely weird. Also behaviour for local collections
> is different, but quite as erratic.
> I've been using digikam for a while now, never had such problems. I guess
> I'll completely re-install digikam - maybe my configuration is flawed..
>
>
>
> --
> Sent from: http://digikam.1695700.n4.nabble.com/digikam-users-f1735189.html

[karsten_df]

Screenshot_20180310_001628.png
<http://digikam.1695700.n4.nabble.com/file/t376440/Screenshot_20180310_001628.png>  

This is actually from a fresh install I just did (all known installation
files deleted prior to installation, however existing database / pictures
re-used). Database & pictures are on a linux server in my network. Fresh
install seems to behave quite as the previous one.



--
Sent from: http://digikam.1695700.n4.nabble.com/digikam-users-f1735189.html

[Maik Qualmann]

It's a simple QDir() operation. The problem must also occur outside with
digiKam. Does it work if you rename the folder with Dolphin?

bool ret = QDir().rename(oldUrl.toLocalFile(), newUrl.toLocalFile());

if (!ret)
{
    ScanController::instance()->resumeCollectionScan();

    errMsg = i18n("Failed to rename Album");
    return false;
}

Maik

Am Samstag, 10. März 2018, 00:20:59 CET schrieb karsten_df:

> Screenshot_20180310_001628.png
> <http://digikam.1695700.n4.nabble.com/file/t376440/Screenshot_20180310_00162
> 8.png>
>
> This is actually from a fresh install I just did (all known installation
> files deleted prior to installation, however existing database / pictures
> re-used). Database & pictures are on a linux server in my network. Fresh
> install seems to behave quite as the previous one.
>
>
>
> --
> Sent from: http://digikam.1695700.n4.nabble.com/digikam-users-f1735189.html

[karsten_df]

just tried that again -
- renamed a directory (being part of a collection on the server) via local
Dolphin =>OK
- after re-scan, new name is visible in dk
- rename directory in dk brings up well known error, directory is actually
NOT renamed
  (but shown with modified name in dk, so the return error seems to be
ignored..)




--
Sent from: http://digikam.1695700.n4.nabble.com/digikam-users-f1735189.html

[karsten_df]

I've done some more testing now, in a completely fresh environment:
- a virtual machine with OpenSUSE Tumbleweed
- a 2nd virtual machine running ubuntu server 16.04.04, hosting mariaDB for
digikam databases, plus a nfs share for pictures (actually containing only
one picture currently)
And.. behaviour is exactly the same:
- rename of directory does NOT work for the collection on the nfs share
- but does work for a local collection
Certainly I can rename the directory on hthe nfs share from dolphin on the
Tumbleweed machine.

So I guess I can rule out any issues related to my databases.
Permissions should not be an issue also, since dolphin has no issues
renaming the folder via the same nfs share.

Anybody running a similar configuration (mySQL / mariaDB on server, pictures
on nfs share on the same server)?



--
Sent from: http://digikam.1695700.n4.nabble.com/digikam-users-f1735189.html

[karsten_df]

karsten_df wrote
> And.. behaviour is exactly the same:
> - rename of directory does NOT work for the collection on the nfs share
> - but does work for a local collection

some more test results:
- in the same virtualized setup as described in prior post,
  - the digikam-5.8.0-01-x86-64.appimage runs fine,
  - while the installed version 5.8.0.6.1 has the issues described earlier
whom should I address this to?




--
Sent from: http://digikam.1695700.n4.nabble.com/digikam-users-f1735189.html

[Gilles Caulier-4]

Interresting. Which Qt version do you use with your system. Look in digiKam Help/Components Info for details.

By comparison, look the same version used in the AppImage. After all, QFile or QDir API used in digiKam to process renaming come from Qt5, and bug exists...

Gilles Caulier 

2018-03-14 20:54 GMT+01:00 karsten_df <[hidden email]>:

karsten_df wrote
> And.. behaviour is exactly the same:
> - rename of directory does NOT work for the collection on the nfs share
> - but does work for a local collection

some more test results:
- in the same virtualized setup as described in prior post,
  - the digikam-5.8.0-01-x86-64.appimage runs fine,
  - while the installed version 5.8.0.6.1 has the issues described earlier
whom should I address this to?

--
Sent from: http://digikam.1695700.n4.nabble.com/digikam-users-f1735189.html

[karsten_df]

Gilles Caulier-4 wrote
> Interresting. Which Qt version do you use with your system. Look in
> digiKam
> Help/Components Info for details.

AppImage uses Qt 5.9.1
Installed version from Tumbleweed uses Qt 5.10.0
(all from the virtual boxes, I'm away from my native setup)

there are a few more diffeneces, see attached file
Components.Components
<http://digikam.1695700.n4.nabble.com/file/t376440/Components.Components>  



--
Sent from: http://digikam.1695700.n4.nabble.com/digikam-users-f1735189.html

[karsten_df]

just verified: Qt version and behaviour on native setup is the same -
AppImage can, installed version can NOT rename directory.
(However, AppImage doesn't show map for geo-tagged pictures)

So is there an issue with Qt 5.10?


karsten_df wrote
> AppImage uses Qt 5.9.1
> Installed version from Tumbleweed uses Qt 5.10.0
> (all from the virtual boxes, I'm away from my native setup)





--
Sent from: http://digikam.1695700.n4.nabble.com/digikam-users-f1735189.html

[Gilles Caulier-4]

2018-03-15 22:08 GMT+01:00 karsten_df <[hidden email]>:

just verified: Qt version and behaviour on native setup is the same -
AppImage can, installed version can NOT rename directory.
(However, AppImage doesn't show map for geo-tagged pictures)

So is there an issue with Qt 5.10?

Good question. I don't know.

Writing a simple unit test can confirm the problem but will not figure where it come.

You must know that Qt is a huge project with a lots of dependencies and a lots of configuration rules. The problem can come from Qt core implementation or from a dependency.

For ex, this is my cmake sub-script to prepare Qt 5.9 before to compile under Centos6 while AppImage build :

https://cgit.kde.org/digikam-software-compilation.git/tree/project/bundles/3rdparty/ext_qt/CMakeLists.txt

Look all the options at each line, and look all skiped framework components not used by digiKam. The Qt 5.9.3 is compiled "simplified" in fact. This is certainly not the case in your Linux distribution.

Gilles Caulier

[Gilles Caulier-4]

Qt has a bugzilla web service where we can found QDir bugs :

https://bugreports.qt.io/browse/QTBUG-12584?jql=text%20~%20%22QDir%22

Perhaps an entry relevant of this problem can be found here...

Gilles Caulier

2018-03-16 9:00 GMT+01:00 Gilles Caulier <[hidden email]>:

2018-03-15 22:08 GMT+01:00 karsten_df <[hidden email]>:

just verified: Qt version and behaviour on native setup is the same -
AppImage can, installed version can NOT rename directory.
(However, AppImage doesn't show map for geo-tagged pictures)

So is there an issue with Qt 5.10?

Good question. I don't know.

Writing a simple unit test can confirm the problem but will not figure where it come.

You must know that Qt is a huge project with a lots of dependencies and a lots of configuration rules. The problem can come from Qt core implementation or from a dependency.

For ex, this is my cmake sub-script to prepare Qt 5.9 before to compile under Centos6 while AppImage build :

https://cgit.kde.org/digikam-software-compilation.git/tree/project/bundles/3rdparty/ext_qt/CMakeLists.txt

Look all the options at each line, and look all skiped framework components not used by digiKam. The Qt 5.9.3 is compiled "simplified" in fact. This is certainly not the case in your Linux distribution.

Gilles Caulier

[Gilles Caulier-4]

(However, AppImage doesn't show map for geo-tagged pictures)

Really. It work like a charm here. All my pictures are geo-tagged.

Can you share some samples where you can reproduce the problem ?

Gilles Caulier

2018-03-15 22:08 GMT+01:00 karsten_df <[hidden email]>:

just verified: Qt version and behaviour on native setup is the same -
AppImage can, installed version can NOT rename directory.
(However, AppImage doesn't show map for geo-tagged pictures)

So is there an issue with Qt 5.10?


karsten_df wrote
> AppImage uses Qt 5.9.1
> Installed version from Tumbleweed uses Qt 5.10.0
> (all from the virtual boxes, I'm away from my native setup)

--
Sent from: http://digikam.1695700.n4.nabble.com/digikam-users-f1735189.html

[karsten_df]

Gilles Caulier-4 wrote
> Can you share some samples where you can reproduce the problem ?

I've uploaded three pictures to Dropbox (too big for nabble..):
https://www.dropbox.com/sh/s77k3wq5n0r9tpj/AABBY9Cc3nmBm2iVZmCKSKdwa?dl=0
- DSCN8627: JPEG, position data in EXIF added by camera
- K6083388: Olympus raw (ORF) position data in EXIF added by camera
- K6133622: Olympus raw (ORF) NO position data in EXIF, but manually added
in digikam
                  (database only, since digikam doesn't write EXIF to Raw,
with good reasons afaik)
There are some screenshots showing correct map diplay for all three using
the installed 5.8.0,
plus one showing the behaviour for the AppImage (map sidebar completely
grayed out).
I only added one screenshot for the AppImage, as it looks the same exactly
for the other two pics.
Maybe I miss some configuration in the AppImage case?



--
Sent from: http://digikam.1695700.n4.nabble.com/digikam-users-f1735189.html

[Maik Qualmann]

This is a locale problem that only occurs with the AppImage (different decimal
separator, period or comma from system). Do you use MySQL as database? As a
workaround you can start the AppImage for example as German: LANG=de path/to/
AppImage.

https://bugs.kde.org/show_bug.cgi?id=374302

Maik

Am Samstag, 17. März 2018, 12:24:50 CET schrieb karsten_df:

> Gilles Caulier-4 wrote
>
> > Can you share some samples where you can reproduce the problem ?
>
> I've uploaded three pictures to Dropbox (too big for nabble..):
> https://www.dropbox.com/sh/s77k3wq5n0r9tpj/AABBY9Cc3nmBm2iVZmCKSKdwa?dl=0
> - DSCN8627: JPEG, position data in EXIF added by camera
> - K6083388: Olympus raw (ORF) position data in EXIF added by camera
> - K6133622: Olympus raw (ORF) NO position data in EXIF, but manually added
> in digikam
>                   (database only, since digikam doesn't write EXIF to Raw,
> with good reasons afaik)
> There are some screenshots showing correct map diplay for all three using
> the installed 5.8.0,
> plus one showing the behaviour for the AppImage (map sidebar completely
> grayed out).
> I only added one screenshot for the AppImage, as it looks the same exactly
> for the other two pics.
> Maybe I miss some configuration in the AppImage case?
>
>
>
> --
> Sent from: http://digikam.1695700.n4.nabble.com/digikam-users-f1735189.html

[karsten_df]

great, thanks - that did the trick. I'm using an external MySQL database
indeed.
So I can use the AppImage as a workaround until the original issue can be
resolved.

Anything I can do to help on the strange behaviour of the installed version?
Should I write a bug ticket?



--
Sent from: http://digikam.1695700.n4.nabble.com/digikam-users-f1735189.html

[Maik Qualmann]

 I will test it the days with an NFS share. I also use openSUSE Tumbleweed. I
looked at the source code of dolphin, dolphin uses KIO::rename(). And
KIO::rename() deactivates the KDirWatch for the directory before renaming it.
We also use a QFileSystemWatcher and remove the monitored directory
beforehand. The QDir::rename function may fail with open files. However, the
KIO::rename () function also removes the parent directory.
We'll see if that's the problem. It will, however, be fixed only in digiKam
6.0.0. I also tend to make the QFileSystemWatcher optional because it
generates many unnecessary events during file operations and not every user
needs the functionality.

Maik

Am Samstag, 17. März 2018, 20:10:51 CET schrieb karsten_df:

> great, thanks - that did the trick. I'm using an external MySQL database
> indeed.
> So I can use the AppImage as a workaround until the original issue can be
> resolved.
>
> Anything I can do to help on the strange behaviour of the installed version?
> Should I write a bug ticket?
>
>
>
> --
> Sent from: http://digikam.1695700.n4.nabble.com/digikam-users-f1735189.html