Bug 350923

Summary: Previous Drag and Drop bug not fixed (but reportedly fixed)
Product: [Applications] digikam Reporter: cahoovjr
Component: Usability-Drag&DropAssignee: Digikam Developers <digikam-bugs-null>
Status: RESOLVED FIXED    
Severity: normal CC: caulier.gilles
Priority: NOR    
Version: 4.11.0   
Target Milestone: ---   
Platform: Microsoft Windows   
OS: Microsoft Windows   
Latest Commit: Version Fixed In: 5.0.0
Sentry Crash Report:

Description cahoovjr 2015-08-03 16:40:11 UTC
[Digikam-users] Files Disappeared After Drag and Drop - Windows
Gilles Caulier caulier.gilles at gmail.com
Tue Feb 5 14:11:52 UTC 2013

    Previous message: [Digikam-users] Files Disappeared After Drag and Drop - Windows
    Next message: [Digikam-users] Hugin Lens Calibrator, LensFun, and digiKam
    Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

It's typically a bug that we have fixed recently with next 3.0.0.

There is a pre-release installer, only for testing. Uninstall 2.9.0
before...

https://docs.google.com/file/d/0B4Esh3gAgC9QcW5nS04zQWVsNGs/edit?usp=sharing

Please test and report

Gilles Caulier


2013/2/5 <jzealman at 9y.com>

> I'm using digiKam 2.9.0 for Windows 7. I'm new to this program and
> I don't know if I just did something wrong or if there is a serious
> bug. When the program started, I added a local folder as an album.
> It worked fine. I created a new album. The album was empty so I
> dragged all the pictures from Windows Explorer into the new album
> icon in digiKam. It asked if I wanted to move here or copy here. I
> clicked on copy here. Then comes the problem. The pictures never
> show up in the folder. What's worse is that even though I clicked
> copy here, ALL the files I dragged into the new album are gone from
> the original folder. Have all my pictures been deleted? I've
> searched for some of the original file names in Windows and nothing
> shows up. Are my pictures moved to a different folder or is this a
> bug and all my pictures are gone? Is there any way to recover them?
> If not, this is a very serious bug.
>
> _______________________________________________
> Digikam-users mailing list
> Digikam-users at kde.org
> https://mail.kde.org/mailman/listinfo/digikam-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/digikam-users/attachments/20130205/8f4740cf/attachment.html>

    Previous message: [Digikam-users] Files Disappeared After Drag and Drop - Windows
    Next message: [Digikam-users] Hugin Lens Calibrator, LensFun, and digiKam
    Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

More information about the Digikam-users mailing list

I found this bug report posted from this user, using Google Search term. It describes the same problem I have detailed in the following report:

Reproducible: Always

Steps to Reproduce:
1. Click and Highlight a File (In a Windows Explorer window or other file listing window) ... the file name will have the same name as its duplicate (but it is a technically single file by all respects to Windows or for that matter, Digikam) into the Digikam interface Album view.

2.Drag that file into Digikam interface Album view, which would be the SAME subdirectory/filename listing as from where you originally pulled it from the Windows "window"   

3. 

Actual Results:  
1. The file will then be obliterated from the Windows Explorer window. The file WON'T be obliterated from the Digikam interface Album view.

2. Two(2) dialog pop-up windows will appear, one asking for a choice of file-naming or alternate    actions, and the other pop-up will be a progress dialog window.

3. If you select the option to rename the file, the filename will be not be reproduced after subsequent clicks to the renaming button, without having apparently creating an additional new copy(file), or the dialog will complain that your reproducing additional same filenames that are to be copied upon itself.

4. Once having this condition, if you now escape from the dialog window(s), neither a new file is created or the original file exists.   
 

Expected Results:  
In case I wanted the choice of overwriting an existing file,  despite the fact that the file is the same photo, that same photo; I wanted to update with a different creation, modification date, or EXIF information(dated older and/or newer), that WASN'T updated exclusively using the Digikam database tools.    The possibility of this could be, from several different scenarios, which for this I won't elaborate, but given the choice to quickly drag and drop files into the database without having to use the Import function for batch processing of many files at once.  In this case,  just the selecting of one file-at-a-time should service an import of a file, and a choice action.

Otherwise the normal work-flow, should have populated into the database as an new imported file, not requesting an update to a file that exists.

Either way, the final result should not be the permanent erasing of the file.

Gilles Caulier caulier.gilles at gmail.com quoted in the previous message to user jzealman at 9y.com:

"It's typically a bug that we have fixed recently with next 3.0.0."

I have installed and uninstalled Digikam Windows versions 3.10 and 4.11.0, and reproduced the same results in both versions. So I am making an assumption that is bug has compiled from as far back as version 2.9.0, without subsequently being fixed, starting with version 3.10.

I have not installed version 3.0.0, to verify if that version EXCLUSIVELY has been fixed with this bug fix as quoted by Gilles Caulier.  I also don't assume that other environmental factors cause this problem, because this same type of work-flow is functioning in software that I use. (i.e. Picasa)   

I am using the software in Windows 7 Service Pack 1. I do not update Windows 7 past this update. So making the assumption that, not updating Windows 7 could be a contributing factor to this bug, if your development team keeps up with these type changes.

But I can also assume that this is not the case, because you have not removed the KDE for Windows warnings, or elaborated likewise with any news of this sort.

I am otherwise quite content to deal with the bugs that are inherent in Windows and in the version(s) developed for Windows exclusively.

I would also like to note that, I would prefer not to be enlisted as a pre-release tester, unless it behooves me to include the same benefits, of:

1. Software testing, increasing my work-flow and giving me the opportunity to have access to the fixed software, which WOULD help my goal(s), I have so dedicated to using this software.

2. Having contributed to the work, to a fine software that has the potential to meet or exceed the expectations of paid software that is cranked out at high prices.
Comment 1 caulier.gilles 2015-08-06 08:16:30 UTC
The last digiKam version from windows is 4.11.0. Please report using this release.

Gilles Caulier
Comment 2 caulier.gilles 2015-08-17 11:26:27 UTC
digiKam 4.12.0 is out :

https://www.digikam.org/node/741

We need a fresh feedback using this release please...
Thanks in advance.

Gilles Caulier
Comment 3 caulier.gilles 2016-05-28 18:23:00 UTC
With next digiKam 5.0.0, we will provide a fully cross-compiled version Windows under Linux where a lots of problems have been fixed.

https://www.flickr.com/photos/digikam/27033685570/in/dateposted-public/

The Windows installer is available here to test :

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

Gilles Caulier