Bug 329438

As far as I know ISO format using such timestamp: "YYYY-MM-DDTHH:MM:SS", but symbol ":" is not allowed for ntfs/windows.

Git commit 7f3459d55dd453f257ece35398175bba22ea4109 by Gilles Caulier.
Committed on 25/01/2015 at 11:39.
Pushed by cgilles into branch 'master'.

Apply patch #90637 from Maik Qualmann to fix image renaming settings rules in Import Tool to work properly while downloading.
Related: bug 342996, bug 314441, bug 307253, bug 342430
FIXED-IN: 4.7.0

M  +3    -1    NEWS
M  +2    -2    utilities/importui/backend/cameracontroller.cpp
M  +67   -44   utilities/importui/main/importui.cpp
M  +1    -0    utilities/importui/main/importui.h
M  +5    -0    utilities/importui/views/importview.cpp
M  +1    -0    utilities/importui/views/importview.h

http://commits.kde.org/digikam/7f3459d55dd453f257ece35398175bba22ea4109

Git commit 0201e6fc8549ac849029daf36eaeadd6ebb4d4ae by Gilles Caulier.
Committed on 25/01/2015 at 13:58.
Pushed by cgilles into branch 'frameworks'.

Backport commit #7f3459d55dd453f257ece35398175bba22ea4109 from git/master to frameworks branch.
Related: bug 342996, bug 314441, bug 307253, bug 342430

M  +3    -3    utilities/importui/backend/cameracontroller.cpp
M  +74   -50   utilities/importui/main/importui.cpp
M  +1    -0    utilities/importui/main/importui.h
M  +5    -0    utilities/importui/views/importview.cpp
M  +1    -0    utilities/importui/views/importview.h

http://commits.kde.org/digikam/0201e6fc8549ac849029daf36eaeadd6ebb4d4ae

digiKam 4.7.0 for Windows is available :

http://download.kde.org/stable/digikam/digiKam-installer-4.7.0-1-win32.exe.mirrorlist

Please test and report.

Thanks in advance

Gilles Caulier

digiKam 4.11.0 Windows installer is available for download :

http://download.kde.org/stable/digikam/digiKam-installer-4.11.0-win32.exe.mirrorlist

New digiKam 5.0.0-beta7 installer for Windows is available for testing :

https://drive.google.com/open?id=0B7yq-xFihT0_SzhxVzF1RDhPbFE

Please report if problem remain with this version.

Thanks in advance

Gilles Caulier

This file still valid using digiKam 5.0.0 ?

Gilles Caulier

This problem still reproducible using last DK 5.4.0 bundle ?

https://drive.google.com/drive/folders/0BzeiVr-byqt5Y0tIRWVWlRJenM

Gilles Caulier

Git commit 2d8d7be73d4b81ed298cd21edae2a7350128fb48 by Maik Qualmann.
Committed on 15/04/2018 at 08:10.
Pushed by mqualmann into branch 'master'.

we always replace the colon to avoid problems with Windows file systems
Related: bug 391312
FIXED-IN: 6.0.0

M  +2    -1    NEWS
M  +0    -6    core/libs/album/albumpropsedit.cpp
M  +1    -5    core/utilities/advancedrename/advancedrenamemanager.cpp

https://commits.kde.org/digikam/2d8d7be73d4b81ed298cd21edae2a7350128fb48

I think, it would be better to replace the colon character unconditionally, not only on the Windows platform. Linux users often want to share photos with Windows users or want to save photos on a medium which is also accessed by Windows computers.

The current implementation already looks different. It queries the file system, whether it is a FAT* or NTFS* file system. It will also replace a whole host of other characters that Windows does not support. In this way, Linux users can continue to use a colon. If from Linux has special characters in the file name and it is to be copied to a Windows file system, then an export tool must correct the file names.

Maik

The strategy is good, but does not reliable work on Linux.

    if (sysType.contains(QLatin1String("FAT")) ||
        sysType.contains(QLatin1String("NTFS")))
    {
        QRegExp regexp(QLatin1String("[?*<>,\\+:=/\";|]"));
        newName.replace(regexp, QLatin1String("_"));
    }

The current code tests for the filesystems "FAT" and "NTFS". On Linux "FAT" filesystems show the name "vfat" in QStorageInfo. NTFS shows as "fuseblk" in QStorageInfo, if NTFS is mounted with "ntfs-3g" like most distributions do. Unfortunately "fuseblk" does not necessarily mean, the it is a NTFS filesystem. There are many FUSE filesystems.

"vfat" is OK, because "FAT" matches the uppercase word "VFAT". For NTFS (ntfs-3g) we need a solution. (Hint: "lsblk -no name,fstype" detects NTFS correctly - see https://unix.stackexchange.com/questions/332712/how-do-i-find-out-what-filesystem-fuse-is-using)

I also do not understand, why "/" is not filtered on Linux. \ / : * ? " < > | are legal characters in Linux filenames (only / and NUL are illegal), but will cause problems anyway, e.g. in the shell.

ReFS and exFAT are also not considered by the code.

The easiest solution is still to filter all possible illegal characters unconditionally.

Generally removing all characters that are not allowed under Windows is not the right solution. Then we have the next bug report from a Linux user who has always used the colon in his file name. At the moment I tend to put "fuseblk" on the blacklist too. The slash "/" is already internally filtered, it can not be entered in the input field, filtering in the result string is not necessary.

Maik

(In reply to Maik Qualmann from comment #13)
> Then we have the next bug report from a Linux user who
> has always used the colon in his file name. [...]The slash "/" is already 
> internally filtered, it can not be entered in the input field, filtering
> in the result string is not necessary.

I think, not much people will use characters like ":" and "*" for filenames, but those characters can be part of the variables, e.g. EXIF variables. I searched for this bug report, because I wanted to insert date+time in the filename, because this makes it possible to sort photos easily by date/time. Unfortunately this does not work with Digikam 5.9.0 + Linux + VFAT media, because [meta:Exif.Image.DateTime] produces filenames with colons (e.g. 2016:12:27 18:54:23.jpg)

The Windows installer have been recompiled with last changes from source code and is available here for testing :

https://files.kde.org/digikam/

Take a care : it's a beta release. Make a database backup before to test.

Gilles Caulier