Project

General

Profile

Bug #8480

Import from Camera Overwrites Images

Added by orbisvicis - almost 9 years ago. Updated over 7 years ago.

Status:
Fixed
Priority:
Low
Category:
General
Start date:
08/16/2012
Due date:
% Done:

100%

Estimated time:
(Total: 0.00 h)
Affected Version:
git development version
System:
bitness:
64-bit
hardware architecture:
amd64/x86

Description

I do this all the time and it's annoying. Anyway, if I selectively import one image, it will be named:
$(YEAR)$(MONTH)$(DAY)_0001.$(FILE_EXTENSION)
And if I then decide later to import another image, it will also be named:
$(YEAR)$(MONTH)$(DAY)_0001.$(FILE_EXTENSION)
The main problem is that darktable will silently overwrite the older image with the newer.

Possible solutions
1] Use the camera's image name scheme... since each subsequent image has an increasing sequence number even if older images are deleted, this is the best way to avoid this problem, ie:
_MG_2624.CR2
_MG_2625.CR2
2] Detect conflict and automatically generate a new sequence number without asking the user.
3] Ask the user. This could be a lot of asking though: if I import 30 images in one session, then 30 images later, darktable would have to ask about 30 conflicting file names


Subtasks

Bug #8863: Importing from camera with "delete originals after import" into existing filmroll name overwrites existing imagesFixedHenrik Andersson

Associated revisions

Revision 08eb87a2 (diff)
Added by Henrik Andersson over 7 years ago

Return a copy of result and let caller free memory, prevents
use of freed result pointer if variables are reused for expansion.

Part of bug #8480.

Revision 5ed8297c (diff)
Added by Henrik Andersson over 7 years ago

Added more checking to camera import code to prevent overwrites.

Fixes #8480

Revision f880b6e8 (diff)
Added by Henrik Andersson over 7 years ago

If we cant get a filename, do NOT continue the process which might
end up with deleted orginal and no image saved locally.

Fixes #8480

History

#1 Updated by Anonymous almost 9 years ago

I can confirm this too.. My friday almost ended in disaster because of this.
With automatic removal from card, this can ruin your day.
Thanks to some god of code for image recovery tools.. ;)

#2 Updated by Henrik Andersson almost 9 years ago

  • Status changed from New to In Progress

#3 Updated by Henrik Andersson almost 9 years ago

Oh that shouldn't ever happen but why dont you guys use ${SEQUENCE} which
is used for serial numbering the images, the variable expander relies on this one
to make all imagenames uniq within a folder, this is the default values in
the camera import settings and i dont know why you guys changed it !

There are 2 steps to solve this:

1 Add some checks in configuration dialog that filnames produced by
the settings produces uniq filenames.. which will force the user
to configure it the right way..

2 Add an additional serialnumber if image exists, last fallback saviour!

/H

#4 Updated by orbisvicis - almost 9 years ago

Thanks for looking into this.

I didn't know ${SEQUENCE} existed, my defaults are:
$(PICTURES_FOLDER)/darktable
$(YEAR)$(MONTH)$(DAY)_$(JOBCODE)
$(YEAR)$(MONTH)$(DAY)_$(SEQUENCE).$(FILE_EXTENSION)
and I've never changed them.

I last deleted all my settings pretty recently (~/.config/darktable, ~/.cache/darktable), unless the settings are stored in gconf - I don't touch those. Anyway in that case darktable should update its user gconf settings imo.

Anyway before/after every upgrade from git I run:
usr/sbin/gconfpkg --uninstall darktable
usr/sbin/gconfpkg --install darktable

#5 Updated by Simon Spannagel almost 8 years ago

  • Target version changed from 1.0.3 to Candidate for next patch release

#6 Updated by Tobias Ellinghaus over 7 years ago

  • Affected Version set to git development version
  • % Done changed from 0 to 20
  • Status changed from New to Incomplete

Could anyone test if this still happens?

#7 Updated by Henrik Andersson over 7 years ago

  • % Done changed from 20 to 100
  • Status changed from Incomplete to Fixed

I found a very critical bug which is the root cause to the problem that is fixed in
08eb87a2, then i added some more checks to current code to file overwrite when
storage structures variables expands to same filename..

Also available in: Atom PDF

Go to top