Bug 232777 - lost images, when they are rotated on (over-)full hd resp. partition.
Summary: lost images, when they are rotated on (over-)full hd resp. partition.
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: Plugin-DImg-JPEG (show other bugs)
Version: 1.1.0
Platform: unspecified Linux
: NOR normal
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-03-31 00:44 UTC by Christian Herzberg
Modified: 2017-07-30 16:13 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In: 2.6.0
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Christian Herzberg 2010-03-31 00:44:22 UTC
Version:           1.1.0 (using 4.3.4 (KDE 4.3.4), Debian packages)
Compiler:          cc
OS:                Linux (i686) release 2.6.33-1.slh.9-sidux-686

I look at my images with digikam and try to rotate one, by clicking the little turned arrow in the upper left in the image view. The following unnormal statement appears in a normal sub windows (translated for this bug report from german lokalized version):

* rotating image „Strichmac3.jpg“
* The rotation of the image failed.
* The image source could not be updated.

The image ended up with 0 Bytes and of course digikam can not show any image preview.

Investigation on the problem leads to a full hd, which could cause this error:
Yesterday I need to backup some files with root and "cp -va /home/foo /media/data-hd/backup/". The copies run without errors and directory sizes are equaly (compared with shell command "du -hs *")

But "df" shows this:
Dateisystem          1K‐Blöcke   Benutzt Verfügbar Ben% Eingehängt auf
/dev/sdb2            161273240 153902648         0 100% /media/disk2part2

delete some old linux isos decrease the used bits but don't increase the available ones. A bit strange, isn't it? I can not copy any file to this partition.

So far, the expected behavior for digikam or the edit plugins should not kill any images, if the diskspace run away, but leave the image unmodified.

Can anyone confirm this?
Thanks for all efforts.
Comment 1 caulier.gilles 2010-03-31 10:48:17 UTC
This problem is relevant of libjpeg incompatibility with recent releases. We have fixed that in digiKam 1.2.0 released yesterday. Please update to this version and try again

Gilles Caulier
Comment 2 Christian Herzberg 2010-05-05 22:28:40 UTC
Dear Gilles,

digiKam 1.2.0 is now with me (resp. with sidux) and KDE SC 4.4.3 also.

So I give this bug the next try. Unfortunately I moved some file away so my diskspace looks like:

Dateisystem          1K‐Blöcke   Benutzt Verfügbar Ben% Eingehängt auf
/dev/sdb2            161273240 145850496   7230812  96% /media/disk2part2

and rotating image is no problem.

But the bug seems for me to be related to a full disk. So I filled my disk again with root:

Dateisystem          1K‐Blöcke   Benutzt Verfügbar Ben% Eingehängt auf
/dev/sdb2            161273240 155930020         0 100% /media/disk2part2

And now the bug is there again:
I try to rotate. the error messages above comes up and the preview can't be displayed anymore.
The file is trimmed to a size of 0 KB:

$ ls -la | grep 100_4671
-rw-r--r--  1 testuser  testuser      0  5. Mai 22:10 100_4671.JPG

Can anyone confirm this behavior?

Thanks for all efforts
Comment 3 Christian Herzberg 2010-05-05 22:31:28 UTC
Because you mentioned libjpeg, here are some version informations from 'apt-cache policy':

# apt-cache policy digikam kipi-plugins libjpeg62 libjpeg7 libjpeg8
digikam:
  Installiert: 2:1.2.0-2
  Kandidat: 2:1.2.0-2
  Versions-Tabelle:
 *** 2:1.2.0-2 0
        700 http://ftp.de.debian.org sid/main Packages
        100 /var/lib/dpkg/status
     2:1.1.0-1 0
        600 http://ftp.de.debian.org testing/main Packages
kipi-plugins:
  Installiert: 1.2.0-2
  Kandidat: 1.2.0-2
  Versions-Tabelle:
 *** 1.2.0-2 0
        700 http://ftp.de.debian.org sid/main Packages
        100 /var/lib/dpkg/status
     1.1.0-1 0
        600 http://ftp.de.debian.org testing/main Packages
libjpeg62:
  Installiert: 6b-16.1
  Kandidat: 6b-16.1
  Versions-Tabelle:
 *** 6b-16.1 0
        700 http://ftp.de.debian.org sid/main Packages
        600 http://ftp.de.debian.org testing/main Packages
        100 /var/lib/dpkg/status
libjpeg7:
  Installiert: 7-2
  Kandidat: 7-2
  Versions-Tabelle:
 *** 7-2 0
        700 http://ftp.de.debian.org sid/main Packages
        600 http://ftp.de.debian.org testing/main Packages
        100 /var/lib/dpkg/status
libjpeg8:
  Installiert: 8a-1
  Kandidat: 8a-1
  Versions-Tabelle:
 *** 8a-1 0
        700 http://ftp.de.debian.org sid/main Packages
        600 http://ftp.de.debian.org testing/main Packages
        100 /var/lib/dpkg/status

Kindest regards
Comment 4 Christian Herzberg 2010-06-08 16:31:19 UTC
Because of data loss this bug should be a "major" one instead of a "normal" bug, shouldn't it?

And maybe there are new infos from developing to test...?

Thanks for all efforts
Comment 5 caulier.gilles 2010-06-08 17:11:47 UTC
update to digiKam and kipi-plugins 1.3.0 and try again. It must be fixed (libjpeg relevant)

Gilles Caulier
Comment 6 Marcel Wiesweg 2011-01-21 16:23:33 UTC
Christian, can you give us the output on the console? The actual operation is done by opening an image read-only, and writing to a temp file. Only if everything is successful, the original is overwritten.
Now, why is no error reported? Anything on the console?
Comment 7 caulier.gilles 2011-12-12 20:22:05 UTC
Christian,

Do you see comment #6 from Marcel ?

Gilles Caulier
Comment 8 caulier.gilles 2012-01-25 10:25:52 UTC
This entry is fixed now with digiKam 2.6.0 where a dedicated implementation is
used to rotate/flip image. There is no progress dialog when image are rotated.
A new Progress Manager have been implemented into status bar (as into Kontact).

digiKam 2.6.0 disabled JPEGLOSSLESS kipi-plugin.  We don't use ImageMagick to process image transformation. 

Gilles Caulier