Project

General

Profile

Feature #10532

Write protected sidecar files

Added by Anonymous almost 5 years ago. Updated almost 5 years ago.

Status:
New
Priority:
Low
Assignee:
-
Category:
General
Target version:
-
Start date:
06/14/2015
Due date:
% Done:

0%

Estimated time:
Affected Version:
1.6.7
System:
all
bitness:
64-bit
hardware architecture:
amd64/x86

Description

All to often I have lost a good processing stack (because darktable does not require an explicit save). To avoid that from happening, I have `chmod -w`ed the sidecar file. Now darktable does not indicate that to the user at all, ever, it just behaves as usual, however not writing changes to the sidecar any more, but to the database only. So sidecar and database are getting out of sync, without the user noticing.

Suggestion: If the sidecar is write protected, generate a new one (like a duplicate), or warn the user every time he opens a file, that the sidecar and database are not in sync.

Of course, the IMHO best thing would be to require to explicitly save a modified history stack in darkroom.

History

#1 Updated by Pascal Obry almost 5 years ago

  • Tracker changed from Bug to Feature
Of course, the IMHO best thing would be to require to explicitly save a modified history stack in darkroom.

No as the sidecar act as a backup in case the database get corrupted (which could mean loosing all edits for all pictures). Not an option, we really want the sidecar to be up-to-date as soon as possible and automatically.

Note also that this cannot be a bug, I have set to "Feature".

#2 Updated by Anonymous almost 5 years ago

Pascal Obry wrote:

No as the sidecar act as a backup in case the database get corrupted (which could mean loosing all edits for all pictures). Not an option, we really want the sidecar to be up-to-date as soon as possible and automatically.

The idea was to write neither to the database nor to the sidecar unless the user actually saves the new history stack, see #10534. But this seems to be a rather quirky idea I'm having there.

#3 Updated by Anonymous almost 5 years ago

Pascal Obry wrote:

No as the sidecar act as a backup in case the database get corrupted
(which could mean loosing all edits for all pictures). Not an
option, we really want the sidecar to be up-to-date as soon as
possible and automatically.

Well, now we have the situation that Darktable stores changes in the
database, but not in a write-protected XMP, and this without the user
noticing. Losing the DB would only allow the user to revert to the
version in the write-protected XMP.

IMHO the user should be alerted whenthe XMP cannot be written to,
especially if it is as important as you claim.

#4 Updated by Pedro Côrte-Real almost 5 years ago

IMHO the user should be alerted whenthe XMP cannot be written to,

especially if it is as important as you claim.

This is a situation the user has created himself. If anything darktable could just force the writing of the XMP anyway. To me seems firmly like a case of "Doctor, it hurts when I do this? So stop doing it.".

#5 Updated by Anonymous almost 5 years ago

Pedro Côrte-Real wrote:

If anything darktable could just force the writing of the XMP anyway.

That would be... stupid.

Darktable could say:

  • Hey user, the XMP is read-only and I'll not let you work on that
    image.
  • Hey user, the XMP is read-only and changes will only be stored in
    the database. But every time you open that file, I'll point out
    the difference to you.

Or it coud do something quite ingenious:

  • Hey user, the XMP is read-only, but I've copied that and created a
    new version for you to work on.

#6 Updated by Pedro Côrte-Real almost 5 years ago

Stefan Klinger wrote:

That would be... stupid.

No more stupid than trying to change files behind darktable's back. Darktable wants to write a file, has permissions to do it, so could very well just do it. I wouldn't do it anyway, failing silently is fine by me in this case, it doesn't occur under normal usage.

(..snip..)
  • Hey user, the XMP is read-only, but I've copied that and created a
    new version for you to work on.

Yeah, darktable could bend over backwards to try and work around the user doing strange things, I'd be very much against it though. it's buying a bunch of complexity to support a strange workflow where you're manually changing file permissions as part of managing a library.

#7 Updated by Anonymous almost 5 years ago

Pedro Côrte-Real wrote:

No more stupid than trying to change files behind darktable's back.

Go read the points 1, 2, 3, and 6 in the darktable FAQ
http://www.darktable.org/about/faq/

Darktable wants to write a file, has permissions to do it, so could
very well just do it.

If there's a readonly flag, then I'd take it as a pretty clear
indication that the user does not want the file to be written to.
Ignoring that would really be a slap in the user's face.

I wouldn't do it anyway, failing silently is fine by me in this
case,

No, failing silently is not an option when damage might occur, as is
the case here.

it doesn't occur under normal usage.

With normal usage you mean that I should not use the usual file system
functionality every operating system provides? Normal usage involves
manipulation of files with file system utilities. Thats what they are
made for.

And besides, if darktable would not have that annoyingly destructive
habit of instantly writing all changes to database and sidecar, this
problem would not exist.

#8 Updated by Pedro Côrte-Real almost 5 years ago

Stefan Klinger wrote:

Go read the points 1, 2, 3, and 6 in the darktable FAQ
http://www.darktable.org/about/faq/

Cute

With normal usage you mean that I should not use the usual file system
functionality every operating system provides? Normal usage involves
manipulation of files with file system utilities. Thats what they are
made for.

With normal usage I mean when we're not up against and adversary trying to write the user's settings to permanent storage.

And besides, if darktable would not have that annoyingly destructive
habit of instantly writing all changes to database and sidecar, this
problem would not exist.

If only we stopped having the habit of saving the user's work to disk...

You're trying to invent a workflow that goes against the way darktable is designed. Don't be surprised when it fails in strange ways.

#9 Updated by Anonymous almost 5 years ago

Pedro Côrte-Real wrote:

You're trying to invent a workflow that goes against the way
darktable is designed. Don't be surprised when it fails in strange
ways.

Yes, that's exactly my point: This design choice is what I criticise,
because it leads to my initial problem:
http://redmine.darktable.org/issues/10532

Don't get me wrong, I'm not saying that darktable's design would be
bad, and I'm sure it's a splendid tool for raw developement. But it's
all too easy to loose a good history stack, and it seems very
difficult to protect one from that.

#10 Updated by Pedro Côrte-Real almost 5 years ago

Stefan Klinger wrote:

Don't get me wrong, I'm not saying that darktable's design would be
bad, and I'm sure it's a splendid tool for raw developement. But it's
all too easy to loose a good history stack, and it seems very
difficult to protect one from that.

That may be true but in that case open feature requests (or lookup existing ones) to solve that instead. Instead you want us to do strange hacks based on the xmp file being write protected.

#11 Updated by Ralf Brown almost 5 years ago

There could be other reasons besides setting the XMP read-only that could cause a write error -- filesystem mounted read-only, filesystem full, bad sector on disk, etc. Darktable should warn the user if it is unsuccessful in updating the XMP.

It should also have an undo system (see #10042 and #8498, and probably others), but in lieu of a full undo system, a compromise might be to preserve old versions of the history stack in the XMP. I think creating a new copy in the XMP whenever the history stack shrinks would be sufficient (at any other time, updates have only added items to the top of the stack or changed the very top entry). Then allowing a roll-back to older versions of the stack stored in the XMP will undo compress-stack and making edits while an entry other than the top one is selected, and thus should eliminate lost history stacks.

Also available in: Atom PDF

Go to top