Bug 387768

Summary: File system corruption after renaming folder
Product: [Applications] digikam Reporter: clem <clemty>
Component: Database-AlbumsAssignee: Digikam Developers <digikam-bugs-null>
Status: RESOLVED FIXED    
Severity: major CC: caulier.gilles, iwannaberich, metzpinguin
Priority: NOR    
Version: 5.7.0   
Target Milestone: ---   
Platform: Microsoft Windows   
OS: Microsoft Windows   
Latest Commit: Version Fixed In: 6.4.0
Sentry Crash Report:
Attachments: 1) initial file/folder
2) lowercase folder in digiKam
3) rename folder to uppercase in explorer
4) both variants visible in digiKam after restart
5) move one folder into the other in digiKam
6) recursive directory structure
scanDirs.patch
scanDirs2.patch

Description clem 2017-12-10 11:08:47 UTC
One of my folders was all lowercase (e.g. "party"), while digiKam was running I renamed it to capital case (e.g. "Party") in the Windows explorer, now digiKam showed two albums, "party" and "Party" with identical files in them, even when quitting and restarting digiKam

when moving the "party" folder into "Party" within digiKam, each "Party" folder in the Windows explorer recursively contained another Party folder - something that should not be possible under Windows

(I could fix the folder structure by copying the pictures from the folder to someplace else, then delete the folder using the bash that came with git)

(Win7 x64)
Comment 1 caulier.gilles 2017-12-10 11:15:41 UTC
Do yo u mean that Windows is not case sensitive with directory names ?

Which files system do you use to host collections on your disk ? NTFS or FAT ?

Gilles Caulier
Comment 2 caulier.gilles 2017-12-10 11:16:24 UTC
The problem is reproducible with image files naming in one album ?
Comment 3 clem 2017-12-10 12:22:02 UTC
Created attachment 109288 [details]
1) initial file/folder

folder "example" (lowercaes)
Comment 4 clem 2017-12-10 12:22:35 UTC
Created attachment 109289 [details]
2) lowercase folder in digiKam
Comment 5 clem 2017-12-10 12:24:11 UTC
Created attachment 109290 [details]
3) rename folder to uppercase in explorer
Comment 6 clem 2017-12-10 12:24:48 UTC
Created attachment 109291 [details]
4) both variants visible in digiKam after restart
Comment 7 clem 2017-12-10 12:25:13 UTC
Created attachment 109292 [details]
5) move one folder into the other in digiKam
Comment 8 clem 2017-12-10 12:25:38 UTC
Created attachment 109293 [details]
6) recursive directory structure
Comment 9 clem 2017-12-10 12:25:59 UTC
filesystem is NTFS (case insensitive) - digiKam seems to think it is case-sensitive
Comment 10 caulier.gilles 2017-12-10 13:28:42 UTC
From wikipedia page :


https://en.wikipedia.org/wiki/Case_sensitivity

"The older Microsoft Windows filesystems VFAT and FAT32 are not case-sensitive, but are case-preserving. The earlier FAT12 filesystem was case-insensitive and not case-preserving, so that a file whose name is entered as readme.txt or ReadMe.txt is saved as README.TXT.[6] Later Windows file systems such as NTFS are internally case-sensitive, and a readme.txt and a Readme.txt can coexist in the same directory. However, for practical purposes filenames behave as case-insensitive as far as users and most software are concerned."

This want meant that even if case sensitivity exist, Microsoft ignore this point voluntary. This is typically a big mess as usual from M$...

Gilles Caulier
Comment 11 caulier.gilles 2018-08-17 21:30:33 UTC
Can you reproduce the dysfunction using digiKam 6.0.0 pre-release bundle
available here :

https://files.kde.org/digikam/
Comment 12 Maik Qualmann 2018-09-15 16:15:13 UTC
*** Bug 398674 has been marked as a duplicate of this bug. ***
Comment 13 Maik Qualmann 2018-09-17 11:13:42 UTC
This is really an interesting problem. At the moment I do not have a solution to not restrict Linux and OSX users. To rename the album under digiKam works without problems and should be done as a workaround at the moment. Externally renamed makes the problem because digiKam can not determine that it is the same folder. Because "Friends" and "FRIENDS" each return a "QFileInfo::exists() == true".

Maik
Comment 14 caulier.gilles 2018-12-31 11:50:13 UTC
Can you reproduce the dysfunction using the last digiKam 6.0.0-beta3 just
released ?

https://www.digikam.org/news/2018-12-30-6.0.0-beta3_release_announcement/
Comment 15 clem 2019-01-04 18:44:05 UTC
(In reply to caulier.gilles from comment #14)
> Can you reproduce the dysfunction using the last digiKam 6.0.0-beta3 just
> released ?

Have there been any commits to resolve this issue? I'd rather not try to destroy the filesystem on my production machine intentionally
Comment 16 Maik Qualmann 2019-09-01 20:10:09 UTC
Created attachment 122448 [details]
scanDirs.patch

This patch fixes the problem. I'll test it internally, because the code is critical for the database if it does not work properly.

Maik
Comment 17 Maik Qualmann 2019-09-03 18:00:07 UTC
Created attachment 122473 [details]
scanDirs2.patch

Updated patch.
Comment 18 Maik Qualmann 2019-09-09 20:44:52 UTC
Git commit e00ade3c4bd32822db4531bf32906633c84e6c53 by Maik Qualmann.
Committed on 09/09/2019 at 20:43.
Pushed by mqualmann into branch 'master'.

fix detection of directory names of Windows file systems
FIXED-IN: 6.4.0

M  +2    -1    NEWS
M  +20   -2    core/libs/database/collection/collectionscanner_scan.cpp

https://invent.kde.org/kde/digikam/commit/e00ade3c4bd32822db4531bf32906633c84e6c53