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)
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
The problem is reproducible with image files naming in one album ?
Created attachment 109288 [details] 1) initial file/folder folder "example" (lowercaes)
Created attachment 109289 [details] 2) lowercase folder in digiKam
Created attachment 109290 [details] 3) rename folder to uppercase in explorer
Created attachment 109291 [details] 4) both variants visible in digiKam after restart
Created attachment 109292 [details] 5) move one folder into the other in digiKam
Created attachment 109293 [details] 6) recursive directory structure
filesystem is NTFS (case insensitive) - digiKam seems to think it is case-sensitive
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
Can you reproduce the dysfunction using digiKam 6.0.0 pre-release bundle available here : https://files.kde.org/digikam/
*** Bug 398674 has been marked as a duplicate of this bug. ***
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
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/
(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
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
Created attachment 122473 [details] scanDirs2.patch Updated patch.
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