[Digikam-devel] [Bug 268831] New: Interrupted-restarted import results in empty file

[Adam Porter]

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

           Summary: Interrupted-restarted import results in empty file
           Product: digikam
           Version: 1.8.0
          Platform: Ubuntu Packages
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: major
          Priority: NOR
         Component: Import
        AssignedTo: digikam-devel at kde.org
        ReportedBy: adam at alphapapa.net


Created an attachment (id=58148)
 --> (http://bugs.kde.org/attachment.cgi?id=58148)
Screenshot of file-replace dialog

Version:           1.8.0 (using KDE 4.6.1) 
OS:                Linux

I was downloading images from my iPhone when my system froze hard.  I don't
know what caused that.  Anyway, I rebooted and went back to the import dialog.

1.  The image it had just finished downloading when the system froze (not the
file which was "downloading" on the screen when it froze) is a zero-byte file
in the album directory.  Digikam didn't notice that the file on the camera
(iPhone) differs from the file in the album on-disk, and so it indicates it is
not a new photo.

2.  When I select and download the photo anyway, it asks me if I want to
replace the file on disk with the file from the camera.  But the replace dialog
shows that both files are zero-byte files, even though the file on the camera
is an intact JPEG file.  I clicked Overwrite and it correctly overwrote the
zero-byte file with the file from the camera--but the dialog should have shown
the file from the camera correctly.

3.  The file it was downloading when the system froze somehow ended up on-disk,
but the metadata (EXIF, etc) was not imported into Digikam's db.  I had to
manually reread the metadata from the image file.

Conclusion: I realize that system freezes aren't supported behavior, however
Digikam should be more robust.  When importing photos, it should look at more
than the filename to determine if an image is new.  It should at the very least
check the filesize.  It ought to check some metadata too, like the EXIF
creation date.  A checksum would be nice, though since it would be slower I
suppose it should be optional.  Personally, I'd trade the extra time for extra
reliability, knowing that Digikam will always import all photos successfully
without any false duplicates.

It also seems to me that Digikam should not mark an image in the db as having
had its metadata imported until it actually has.

Reproducible: Didn't try




OS: Linux (i686) release 2.6.35-28-generic
Compiler: cc

-- 
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.