Project

General

Profile

Bug #10661

send to trash buggy

Added by Pascal Obry over 3 years ago. Updated over 3 years ago.

Status:
Fixed
Priority:
Critical
Assignee:
Category:
-
Start date:
10/11/2015
Due date:
% Done:

100%

Affected Version:
git development version
System:
all
bitness:
64-bit
hardware architecture:
amd64/x86

Description

There is some issue with the send to trash and the handling of local copies. It seems that the send to trash do not check for this case.

Also, dt removes images even if a local copy has been created and the original is not present. This is a quite serious regression.

To reproduce issue 1:

$ mkdir one
$ cp <APICTURE> one/

- open dt
- import "one" folder
- select the image
- click: trash

=> display: "cannot remove local copy when the original file is not accessible." 

=> expected: no message, "one" folder removed as empty, here "one" folder stays empty

To reproduce issue 2 (local copies):

$ mkdir one
$ cp <APICTURE> one/

- open dt
- import "one" folder
- click "copy locally" 
- open a terminal and rename "one" directory to "Xone" for example
- do any edit in darkroom
- go back to lighttable
- select the single image in one collection 
- click: trash

=> dt removes the picture and associated xmp

=> nothing happens the message "cannot remove local copy when the original file is not accessible." is displayed.

Associated revisions

Revision 5c46d7ea
Added by Pascal Obry over 3 years ago

Fix handling of trash.

It fixes 2 issues:

1. we do not want to delete a picture with a local copy when the original
is not present.

2. we want to be able to delete a picture without a local copy.
(misleading error message)

Fixes #10661

History

#1 Updated by Pascal Obry over 3 years ago

I have a proposal to fix this issue:
https://github.com/darktable-org/darktable/pull/994

#2 Updated by Pascal Obry over 3 years ago

  • % Done changed from 0 to 70
  • Status changed from New to Patch attached

#3 Updated by Pedro Côrte-Real over 3 years ago

I don't understand what you are suggesting in issue 2. We shouldn't allow users to delete images that have local copies?

#4 Updated by Pascal Obry over 3 years ago

Yes, exactly. If you have a local copy and the original is not accessible and there is some modification done off-line we should not allow the deletion on the xmp otherwise you'll loose your off-line edits.

#5 Updated by Pascal Obry over 3 years ago

BTW, just to make things clear these are regressions on Git master only at the moment.

#6 Updated by Pedro Côrte-Real over 3 years ago

Yes, exactly. If you have a local copy and the original is not accessible and there is some modification done off-line we should not allow the deletion on the xmp otherwise you'll loose your off-line edits.

The user has asked us to delete the file from the collection, the fact that we can't reach some other file shouldn't prevent us from doing it. Could you please explain what local copies is supposed to do? Because it seems you are expecting it to enable a very specific workflow.

#7 Updated by Pascal Obry over 3 years ago

I don't understand your comments. Again these are regressions very recently introduced in dt. The behavior I'm talking about is the one that has been developed and agreed on long time ago now.

Could you please explain what local copies is supposed to do?

It is on the manual, this is supported in current stable branch 1.6.

To make it short it create a local-copy of a picture (for example because it is on a external drive and you want to work on it while on train). But when you have done modifications on local-copy a .xmp is stored on your computer locally. You must resync it when the external drive is connected again. And of course while the external drive is not connected you do not want to be able to remove the .xmp nor local-copy as you'll just loose the edits you've done on the train.

And this is what is done since a long time on 1.6 branch.

#8 Updated by Pedro Côrte-Real over 3 years ago

And of course while the external drive is not connected you do not want to be able to remove the .xmp nor local-copy as you'll just loose the edits you've done on the train.

This is what I don't understand. If the user is asking for delete of the image we should just delete it. He's not asking for delete of the local copy, he's asking for delete of the image from the collection, so any edits should be deleted too. The only problem with this is that we won't be able to also delete the image from storage, but that's just the same as when we ask for delete of an image for which the underlying file is gone (at which point it's just a remove).

#9 Updated by Pascal Obry over 3 years ago

Sorry I don't understand. How can you delete a file that is not accessible?

#10 Updated by Pedro Côrte-Real over 3 years ago

Delete, does two things, it physically deletes the file from disk and removes it from the collection. So here's my expectation of what delete/trash should do in the various scenarios:

1) no copy, file is available: delete/trash file and xmp, remove image from collection
2) no copy, file is not available: just remove image from collection
3) file and copy are available: delete/trash files and xmps, remove image from collection
4) file is not available, copy is: delete/trash copy and its xmp, remove image from collection
5) file is available, copy is not: delete/trash file and its xmp, remove image from collection
6) neither file nor copy is available: just remove image from collection

In all scenarios I'd remove the image from the collection. The corner cases are 2), 4), 5), and 6). 5) seems like not a problem to me. The copy is gone for some reason, just ignore it. For 2/4/6 we could potentially delete the file when we next have it available but that sounds dangerous. It may be simpler to just warn the user on delete that we can't remove the original because it doesn't seem to be available.

#11 Updated by Pascal Obry over 3 years ago

4) file is not available, copy is: delete/trash copy and its xmp, remove image from collection

No this is plain wrong. In this case the original file will remain on disk forever.

5) file is available, copy is not: delete/trash file and its xmp, remove image from collection

That's not possible :) The local copy is local. But if for some reasons 5 happens it is what is done today.

All other points are ok.

So, only for point 4 we disagree and I have very strong objection for your proposal. I do want that the deletion be refused until the original is on-line and can be properly removed.

#12 Updated by Pedro Côrte-Real over 3 years ago

I do want that the deletion be refused until the original is on-line and can be properly removed.

I don't particularly care, and the user can just use remove instead anyway.

#13 Updated by Pascal Obry over 3 years ago

  • Assignee set to Pascal Obry
  • % Done changed from 70 to 100
  • Status changed from Patch attached to Fixed

Also available in: Atom PDF