[digikam] [Bug 381625] New: Copying/Moving photograph files between albums does not give Overwrite/Rename/Cancel options if file with same name exists in the destination album.

[aslam karachiwala]

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

Bug ID: 381625
Summary: Copying/Moving photograph files between albums does
not give Overwrite/Rename/Cancel options if file with
same name exists in the destination album.
Product: digikam
Version: 5.5.0
Platform: Kubuntu Packages
OS: Linux
Status: UNCONFIRMED
Severity: major
Priority: NOR
Component: general
Assignee: digikam-***@kde.org
Reporter: ***@mythicflow.com
Target Milestone: ---

System: Kubuntu 16.04

This issue appeared after recent upgrade to digiKam 5.5. Prior to the upgrade,
when copying/moving a photograph file to an album that already contained a file
with the same name, a dialog was presented with options to overwrite the
existing file, rename the incoming file, or cancel the operation. Now, with v.
5.5, these options are not provided if a copy/move is attempted to a location
where a file with the same name already exists. All that happens now is a
notification saying a file with the same name already exists, and the copy/move
apparently aborts.

Bug 377719 may be related.

[aslam karachiwala]

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

aslam karachiwala <***@mythicflow.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@mythicflow.com

[b***@kde.org]

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

***@gmail.com changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@gmail.com
Component|general |Usability

[b***@kde.org]

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

***@gmail.com changed:

What |Removed |Added
----------------------------------------------------------------------------
Component|Usability |FilesIO-Engine

[Kris]

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

Kris <***@gmail.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@gmail.com

--- Comment #1 from Kris <***@gmail.com> ---
I also have this issue in Suse Leap and Mint 18.2 with 5.5 and 5.7 Appimage and
from repo. Tried using 5.4 Appimage after seeing the post here and still having
this issue. Would be willing to try 5.3 Appimage but can no longer find it
anywhere. Next step is to use 4.14 but I'd like to stay with >5.0

[b***@kde.org]

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

--- Comment #2 from ***@gmail.com ---
Try the 5.8.0 pre-release AppImage here :

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

Note : older AppImage are in the attic :

https://download.kde.org/Attic/digikam/

[Kris]

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

--- Comment #3 from Kris <***@gmail.com> ---
Tried 5.8 and 5.3 appimage. No joy on either. Just for on whim, I installed a
fresh copy of Ubuntu 16.04 (as opposed to Mint 18.2) on a separate partition to
test it out and it happed there as well.

[Simon]

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

Simon <***@gmail.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@gmail.com

--- Comment #4 from Simon <***@gmail.com> ---
This functionality is currently not implemented, so trying new version won't
help until somebody actually implements it.

[Maik Qualmann]

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

Maik Qualmann <***@gmail.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@gmail.com

--- Comment #5 from Maik Qualmann <***@gmail.com> ---
I also do not know whether I would like this dialog window. Personally I had
never desire to decide by the small thumbnail and the file size, whether it is
the same file. I would suggest that we rename an existing file with a counter
and always copy it. Gilles, Simon and Mario how do you see that?

Maik

[Mario Frank]

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

Mario Frank <***@uni-potsdam.de> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@uni-potsdam.de

--- Comment #6 from Mario Frank <***@uni-potsdam.de> ---
(In reply to Maik Qualmann from comment #5)

Post by Maik Qualmann
I also do not know whether I would like this dialog window. Personally I had
never desire to decide by the small thumbnail and the file size, whether it
is the same file. I would suggest that we rename an existing file with a
counter and always copy it. Gilles, Simon and Mario how do you see that?
Maik

Hi Maik,

I think you are right - the thumbnail and file size are not always sufficient
to decide whether the files are identical. The solution using a counter would
be a valid solution. But in this case, the user should be informed that there
were
clashes so he can review the files.

[Kris]

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

--- Comment #7 from Kris <***@gmail.com> ---
(In reply to Simon from comment #4)

Post by Simon
This functionality is currently not implemented, so trying new version won't
help until somebody actually implements it.

Does this mean my best course of action(for right now) would be to use ver 4.14
or lower?

[Simon]

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

--- Comment #8 from Simon <***@gmail.com> ---
(In reply to Kris from comment #7)

Post by Kris
Does this mean my best course of action(for right now) would be to use ver
4.14 or lower?

A big fat no. Removing huge stability and performance benefits (and other
features) just for being able to replace files on moving is nothing that I will
advice. Using a file manager to work around this whenever it comes up seems
like the far better option.

@Maik @Mario:
Automatic renaming creates a messy state and is not what I would expect. Most
other tools I know will let you decide whether to abort, overwrite, keep both
(for one item or all) based on last modified date and file size. Adding a
thumbnail is an additional info we as a DAM add. If this dialog is annoying, we
can add a config option to select always keep both. I wouldn't offer a config
option to automatically overwrite, as this amounts to handing the user a loaded
gun to shoot himself in the foot (lose data).

[aslam karachiwala]

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

--- Comment #9 from aslam karachiwala <***@mythicflow.com> ---
(In reply to Simon from comment #8)

Post by Simon
(In reply to Kris from comment #7)
Automatic renaming creates a messy state and is not what I would expect.
Most other tools I know will let you decide whether to abort, overwrite,
keep both (for one item or all) based on last modified date and file size.
Adding a thumbnail is an additional info we as a DAM add. If this dialog is
annoying, we can add a config option to select always keep both. I wouldn't
offer a config option to automatically overwrite, as this amounts to handing
the user a loaded gun to shoot himself in the foot (lose data).

I concur.

Post by Simon
let you decide whether to abort, overwrite, keep both (for one item or all) based on last modified date and file size.

Any new behavior should be a separate issue to be evaluated as a feature
request.

Also,the status of this bug should be changed to CONFIRMED.

[b***@kde.org]

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

--- Comment #10 from ***@gmail.com ---
Hi all,

I just read this thread late, so no i don't have all information about the
problem.

But, these are my tips :

1/ The rename dialog is problematic for DAM workflow.
2/ Older DK version provide a dialog in case of renaming. This one come from
KIO widgets collection, and depend of KIO protocol which is not portable due to
run-time dysfunction and puzzle. So please no KIO back...
3/ Another file in bugzilla ask to give a progress indication while copy/move
items between albums. this i snot yet implemented if i'm not too wrong.
4/ We have the progress manager, taken and ported to digiKam form KMail version
4. There are some capabilities to ask feedback from the progress widget if i
remember. I recommend to use the progress manager and to try to use it in case
of conflicts where users need to give a feedback.
5/ Remember also the a popup widget, already used in Import tool when the
camera is not joignable, to ask to the user to turn on or re-connect the
camera. This can be used in this kind of situation.

Gilles

[Simon]

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

--- Comment #11 from Simon <***@gmail.com> ---
(In reply to caulier.gilles from comment #10)

Post by b***@kde.org
1/ The rename dialog is problematic for DAM workflow.

I don't quite understand what the problem is?

[b***@kde.org]

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

--- Comment #12 from ***@gmail.com ---
For a fast workflow, with the minimalist user feedback to quickly process the
files.

Gilles Caulier

[Elle Stone]

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

Elle Stone <***@ninedegreesbelow.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@ninedegreesbelow.com

--- Comment #13 from Elle Stone <***@ninedegreesbelow.com> ---
I'm trying to sort through a *lot* of image files - for which there are quite a
few duplicates and also quite a few files in the wrong folder. Whenever I move
an image file from one album to another, if there is already a file by that
name, two things happen:

1. A "popup" - very discrete and easy to overlook, sort of glides up from the
bottom of the screen to say that there is already a file by the same name in
the destination album. It's very easy to overlook this "glide up" and very
discrete notice. As noted already, there are no options provided to "overwrite"
or "move and rename" or "do nothing".

2. The thumbnail does immediately - but only temporarily! - disappear from the
album currently being viewed!!! This is not a good thing!!! It looks like the
image was actually moved, but it wasn't, and eventually the "moved" item shows
back up in the original album.

Going to the file manager to move these files around really isn't an option as
the file names all are very similar. I guess I'll try opening another image
viewer, though that will make the screen very crowded.

This is on digiKam 5.7.0.

Automatically renaming with an added number doesn't sound like a good solution.
In my case it would just create more files that I'd need to sort through. The
simplest thing would be to simply not move the file at all, and also don't make
it *look* like the file was moved, which is currently what is happening.
Although I am running Gentoo, so perhaps this "temporarily disappears from
view" problem is specific to my Gentoo distribution.

[Kris]

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

--- Comment #14 from Kris <***@gmail.com> ---
(In reply to Elle Stone from comment #13)

Post by Elle Stone
2. The thumbnail does immediately - but only temporarily! - disappear from
the album currently being viewed!!! This is not a good thing!!! It looks
like the image was actually moved, but it wasn't, and eventually the "moved"
item shows back up in the original album.

This happens to me, too, in most, if not all the iterations I checked. I have
to Refresh" which does not just refresh the folder I'm in, but instead the
whole database. But this does fix the 'missing thumbnail after unsuccessful
move' issue if I happen to see the notice that the file was not moved.

(In reply to Simon from comment #8)

Post by Elle Stone

Post by Simon
(In reply to Kris from comment #7)
Does this mean my best course of action(for right now) would be to use ver
4.14 or lower?

A big fat no. Removing huge stability and performance benefits (and other
features) just for being able to replace files on moving is nothing that I
will advice. Using a file manager to work around this whenever it comes up
seems like the far better option.

I understand the performance hit I would take, I have used less than version
5.0 before, but using a file manager is not an option here I believe. I am
using Digikam after trying out Shotwell, Darktable, Gthumb, and Gwenview. I
have tried using many different file managers before I ever posted to this
fourum: Dolphin, Nemo, Midnight Commander, Krusader, Konqueror, Double
Commander, muCommander, XnView MP and FreeCommander (Windows Only). I am
resorting to using XnView MP because it is closest to the interface of Digikam
that works in Linux. It is a poor substitute to Digikam even for sorting
photos. If FreeCommander worked in Linux or if Ext2fs was more stable at
writing to a Linux partition, I would not be here. FreeCommander is solidly
windows based and I wish to maintain my files on a Linux drive (Read:Not NTFS
or FAT based). I like using digikam and if I have to use 4.14 to be able to
move files effectively, then that is what I will do. Considering the amount of
effort I have put in trying to find a stable substitute, at this point severely

Post by Elle Stone
(In reply to caulier.gilles from comment #10)
2/ Older DK version provide a dialog in case of renaming. This one come from
KIO widgets collection, and depend of KIO protocol which is not portable
due to run-time dysfunction and puzzle. So please no KIO back...

If I'm understanding this correctly the functionality isn't broken, but rather
does not exist because the KInputOutput protocol can't be utilized or is
somehow incompatible with Digigkam 5 and above. This was responsible for the
pop-up dialog. So this may not be fixed for sometime, correct?

I love this program and I very much understand what it means to be
open-source/community driven. I have alot of respect for you programmers and
the amount of work and code you have to do to keep up a program this advanced.
This is by no means a complaint. Any advice you can give either by suggesting a
comparable file manager or photo program other than the ones I listed above,
I'm all ears. When I've managed to sort my +500,000 photos into a more
manageable hierarchy I will certainly be back to using digikam.

These are the thing I need in a replacement File Manager/DAM:

1/ Custom file naming (shotwell does not do this. You are locked into a
chronological file tree)

2/ Has a preview window (many file managers don't do this).

3/ Has a thumbnail view and a film roll view like in digikam and can be switch
easily (surprisingly hard to find)

4/ Can handle previewing and thumbnailing NEF,JPG,PNG,GIF,TIFF files.

5/ Has a Database file as this seems to be the only way to handle this many
files quickly.

6/ (Not a deal breaker but would be nice) A move to folder dialog similar to
digikams

Thank you for your time and knowledge.

[Simon]

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

--- Comment #15 from Simon <***@gmail.com> ---
About my recommendation to not downgrade: This is a personal recommendation, so
obviously your needs/view may differ. I know that my proposed work-around is
far from optimal (it's a work-around).

(In reply to Kris from comment #14)

Post by Kris

Post by Simon
(In reply to caulier.gilles from comment #10)
2/ Older DK version provide a dialog in case of renaming. This one come from
KIO widgets collection, and depend of KIO protocol which is not portable
due to run-time dysfunction and puzzle. So please no KIO back...

If I'm understanding this correctly the functionality isn't broken, but
rather does not exist because the KInputOutput protocol can't be utilized or
is somehow incompatible with Digigkam 5 and above. This was responsible for
the pop-up dialog. So this may not be fixed for sometime, correct?

To my understanding this is partially correct: It has been removed due to
problems with KIO, however it I don't think KIO is necessary for such a dialog,
it could absolutely be done "internally". The assessment that it may require
some time to get done is potentially correct, as someone needs to invest some
time in it and the amount of work to be done on digikam is huge compared to the
available dev time - Gilles and Maik are doing a lot of work on it, yet there
is always more to do.

In my opinion the use case of such a dialog is apparent and backed up by user
reports, and the current state is definitely not ideal (e.g. the disappearing
items while they weren't actually moved). Either diving into the code yourself
(help would be gladly provided) or subscribing to this issue and hoping for the
bests are your options with digikam at this time regarding this.

[Maik Qualmann]

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

--- Comment #16 from Maik Qualmann <***@gmail.com> ---
Git commit 296632cb79d67b6166840d406182bcd71623ca6d by Maik Qualmann.
Committed on 13/03/2018 at 21:45.
Pushed by mqualmann into branch 'development/6.0.0'.

first step to factoring the IOJob class with a IOJobData container
To perform database operations only after successful file operation
or to add a dialog for user intervention
Related: bug 372763, bug 377719

M +125 -173 libs/database/utils/dio.cpp
M +23 -31 libs/database/utils/dio.h
M +1 -0 libs/iojobs/CMakeLists.txt
A +219 -0 libs/iojobs/iojobdata.cpp [License: GPL (v2+)]
A +91 -0 libs/iojobs/iojobdata.h [License: GPL (v2+)]
M +12 -8 libs/iojobs/iojobsmanager.cpp
M +10 -16 libs/iojobs/iojobsmanager.h
M +22 -26 libs/iojobs/iojobsthread.cpp
M +11 -22 libs/iojobs/iojobsthread.h

https://commits.kde.org/digikam/296632cb79d67b6166840d406182bcd71623ca6d

[b***@kde.org]

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

--- Comment #17 from ***@gmail.com ---
Can you reproduce the dysfunction using digiKam 6.0.0 pre-release bundle
available here :

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

[Kris]

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

Kris <***@gmail.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
Version|5.5.0 |6.0.0

--- Comment #18 from Kris <***@gmail.com> ---
I seem to be having issues with the Win64 version loading/crashing. I will set
up my Linux OS and try again later.

[aslam karachiwala]

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

--- Comment #19 from aslam karachiwala <***@mythicflow.com> ---
(In reply to caulier.gilles from comment #17)

Post by b***@kde.org
Can you reproduce the dysfunction using digiKam 6.0.0 pre-release bundle
https://files.kde.org/digikam/

Yes, I can reproduce the issue with
digikam-6.0.0-git-20180817T182155-x86-64.appimage.