digiKam › digikam-devel

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

Classic

List

Threaded

15 messages Options

Bugzilla from adam@alphapapa.net

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

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: [hidden email]
ReportedBy: [hidden email]

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.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

Bugzilla from adam@alphapapa.net

[Bug 268831] Interrupted-restarted import results in empty file

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

--- Comment #1 from Adam Porter <adam alphapapa net> 2011-03-18 17:49:24 ---
This bug is worse than I realized. A total of 12 images ended up as zero-byte
files on the disk in the album directory. But:

1. Digikam shows them as not-new images in the import dialog.

2. In the on-disk album view, Digikam displays thumbnails and metadata for all
of these images which are zero bytes on the disk! Only when double-clicking
the thumbnail does Digikam say "Cannot display preview for..."

So unless the user opens the album directory in Dolphin and verifies for
himself that the files are intact, he may cheerfully delete his only copies of
the images from his camera.

I am using ext4, by the way.

Perhaps fortuitously, I was reading a Debian bug about dpkg running on ext4
filesystems today and I believe Theodore Ts'o's solution may be applicable
here:

http://article.gmane.org/gmane.linux.debian.devel.bugs.general/771761

I suspect Digikam isn't even calling fsync as images are downloaded from the
camera. That would be ok if it didn't think they were downloaded successfully,
because they could be redownloaded/reimported after rebooting. But Digikam
puts both the thumbnails and EXIF metadata of unwritten files into the
database, and displays them in the album view as if the images are intact
on-disk, leaving the poor, unsuspecting user with no idea that the files were
never written to the disk.

I'm sure we can all agree that Digikam should always fail safely and assume
nothing when it comes to protecting users' data, right? Personally, I hate
having to babysit software to make sure it does the right thing. :)

--
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

Gilles Caulier-4