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

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/

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.

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

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

(In reply to Maik Qualmann from comment #5)
> 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.

(In reply to Simon from comment #4)
> 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?

(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.

@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).

(In reply to Simon from comment #8)
> (In reply to Kris from comment #7)
> 
> @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).

I concur.

I suggest this functionality be restored to its previous state, i.e.:

> 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.

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

(In reply to caulier.gilles from comment #10)
> 1/ The rename dialog is problematic for DAM workflow.

I don't quite understand what the problem is?

For a fast workflow, with the minimalist user feedback to quickly process the files.

Gilles Caulier

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.

(In reply to Elle Stone from comment #13)

> 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)
>>(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 downgrading seems like my only choice. Especially considering :

> (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.

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)
> > (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.

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

Can you reproduce the dysfunction using digiKam 6.0.0 pre-release bundle
available here :

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

I seem to be having issues with the Win64 version loading/crashing. I will set up my Linux OS and try again later.

(In reply to caulier.gilles from comment #17)
> Can you reproduce the dysfunction using digiKam 6.0.0 pre-release bundle
> available here :
> 
> https://files.kde.org/digikam/

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

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 #20)
> 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/

Yes, I can reproduce this issue with digikam-6.0.0-beta3-20181228T114626-x86-64.appimage.

Good news,

After 2 weeks of works, the pre-release 6.1.0 bundles are now reconstructed from scratch with:

- All OpenCV options for CUDA, OPenMP, and OPenCL disabled to prevent crashes
in face management.
- A large upgrade of Qt5 from 5.9.7 to 5.11.3.
- An upgrade to KF5 5.55.
- An upgrade to Ffmpeg 3.3.9
- The fontconfig/freetype integration in the bundle to reduce system
dependencies

Files can be downloaded here :

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

Please test and report.

Gilles Caulier

(In reply to caulier.gilles from comment #22)
> Good news,
> 
> After 2 weeks of works, the pre-release 6.1.0 bundles are now reconstructed
> from scratch with:
> 
> - All OpenCV options for CUDA, OPenMP, and OPenCL disabled to prevent crashes
> in face management.
> - A large upgrade of Qt5 from 5.9.7 to 5.11.3.
> - An upgrade to KF5 5.55.
> - An upgrade to Ffmpeg 3.3.9
> - The fontconfig/freetype integration in the bundle to reduce system
> dependencies
> 
> Files can be downloaded here :
> 
> https://files.kde.org/digikam/
> 
> Please test and report.
> 
> Gilles Caulier

I can reproduce this issue with  digikam-6.1.0-git-20190307T101229-x86-64.appimage.

I can reproduce this issue with digikam 6.4.0 revision d4189399d3b9a70e172e2e4c619548c5dd933280

Dario,

This problem is certainly fixed with next 7.0.0.

Please check with current 7.0.0 release candidate Linux AppImage bundle, available here :

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

Gilles Caulier

Well, with digiKam-7.0.0 there is the possibility to cancel all file operations, undo and restore from trash have been added. The dialog for overwriting or renaming is currently available for the function for renaming items. The dialog for copying or moving albums / files is on my TODO list, but at the moment there are more important things.

Maik

*** Bug 422112 has been marked as a duplicate of this bug. ***

Git commit 312a57751d604899f853851213b180e3a74b25d9 by Maik Qualmann.
Committed on 27/06/2020 at 15:13.
Pushed by mqualmann into branch 'master'.

add simple file conflict dialog when file conflicts are detected
FIXED-IN: 7.0.0

M  +2    -1    NEWS
M  +67   -5    core/libs/database/utils/ifaces/dio.cpp
M  +37   -3    core/libs/iojobs/iojob.cpp
M  +12   -0    core/libs/iojobs/iojobdata.cpp
M  +11   -0    core/libs/iojobs/iojobdata.h
M  +40   -0    core/libs/threadimageio/engine/dfileoperations.cpp
M  +10   -2    core/libs/threadimageio/engine/dfileoperations.h

https://invent.kde.org/graphics/digikam/commit/312a57751d604899f853851213b180e3a74b25d9