GrahamByrnes commented 4 years ago

Copy an image file into a folder, import it to dt. Take it into darkroom and do some trivial editing. Use selected images to send the image to trash.

Verify in the folder that the dng is gone but the xmp remains. Also, the folder hasn't been deleted because it still contains the xmp.

Expected behaviour: the xmp should be deleted at the same time as the dng, and the folder should then be deleted since it's empty.

dt 3.1.0+547 gb447df7c8 Built via msys64 Windows 10pro build 18362, 19h1 release 190318-1202

GrahamByrnes commented 4 years ago

PS If I create a duplicate, then delete the duplicate, the second xmp is correctly deleted.

TurboGit commented 4 years ago

Looks like a Windows specific issue. Will require a Windows dev.

GrahamByrnes commented 4 years ago

Note that it was working fine under 3.1.0+426.

todd-prior commented 4 years ago

I have the same behaviour...on Windows as well...thanks for reporting @GrahamByrnes

GrahamByrnes commented 4 years ago

An extra data point: if I edit an image, then make a new version, then delete the original, then delete the duplicate, all goes as expected.

I have suspicions regarding the common/image.c function dt_image_find_duplicates which was recently added as shared code inside jobs/control_jobs.c

There is a windows specific bit of code in dt_image_find_duplicates which is supposed to deal with the wild-card issue of finding all the associated xmp's... and it is suspiciously brief compared with similar code elsewhere.

GrahamByrnes commented 4 years ago

978:image.c

ifdef _WIN32

// Windows only accepts generic wildcards for filename static const gchar *glob_patterns[] = { "", "__????", NULL };

else

(editor seems to suppress single characters... there is an underscore???? in the code Should that list also contain "??" grrrr underscore??

GrahamByrnes commented 4 years ago

(Sorry, my confusion with github confusion)

GrahamByrnes commented 4 years ago

Nope, that didn't help...

GrahamByrnes commented 4 years ago

Some self documentation that might help others, or me if my brain gets wiped at work :-)

I've been looking at this a bit more now that I'm getting back into the c-habit. First, the wildcard issue above: ? is a wildcard for a single character unless the next char is "." So "_????" is indeed a wildcard for the "_02" in foo_02.DNG.xmp

Moving on, the two related issues are: a) primary (version==0, foo.DNG.xmp) sidecar files are not deleted when the image is deleted; b) existing version 0 sidecar file is not read when the image is moved, deleted from the db, and then re-loaded.

These seem consistent with a failure to include the version 0 of the xmp in the list of files to be a) deleted or b) read. I was misled into racking my brain over dt_image_find_duplicates in src/common/image.c, but I'm now convinced by the code and the behaviour that it's fine: there is no problem finding the duplicates, it's the original that causes problems :-D

Soo... current suspicions are on the loop over the list of detected filepaths in dt_image_read_duplicates (lines 1035 & ff the same file). In particular, there is this little slice of code

`const int newid = dt_image_duplicate_with_version(id, version);

dt_image_t *img = dt_image_cache_get(darktable.image_cache, newid, 'w');

(void)dt_exif_xmp_read(img, xmpfilename, 0);

dt_image_cache_write_release(darktable.image_cache, img, DT_IMAGE_CACHE_RELAXED);`

I need to chase down some of these functions then.

jenshannoschwalm commented 4 years ago

I had a look at the - for me - relevant code. I rather suspect dt_control_delete_images_job_run in control_jobs.c

    // remove from disk:
    if(duplicates == 1)
    {
      // first check for local copies, never delete a file whose original file is not accessible
      if (dt_image_local_copy_reset(imgid))
        goto delete_next_file;

      snprintf(imgidstr, sizeof(imgidstr), "%d", imgid);
      _set_remove_flag(imgidstr);
      dt_image_remove(imgid);

      // there are no further duplicates so we can remove the source data file
      delete_status = delete_file_from_disk(filename, &delete_on_trash_error);
      if (delete_status != _DT_DELETE_STATUS_OK_TO_REMOVE)
        goto delete_next_file;

      // all sidecar files - including left-overs - can be deleted;
      // left-overs can result when previously duplicates have been REMOVED;
      // no need to keep them as the source data file is gone.

      GList *files = dt_image_find_duplicates(filename);

      GList *file_iter = g_list_first(files);
      while(file_iter != NULL)
      {
        delete_status = delete_file_from_disk(file_iter->data, &delete_on_trash_error);
        if (delete_status != _DT_DELETE_STATUS_OK_TO_REMOVE)
          break;
        file_iter = g_list_next(file_iter);
      }

      g_list_free_full(files, g_free);
    }

I guess the if (delete_status != _DT_DELETE_STATUS_OK_TO_REMOVE) checks might not be correct so we could still have some sidecars.

On linux this works just right for me, don't know about dt_win_file_trash called by delete_file_from_disk.

BTW the #ifdef _WIN32 sections using dirname seem to be leftovers.

GrahamByrnes commented 4 years ago

Thanks Hanno, I'll have another look there. I have some other windows issues just now :-(

Le lun. 2 mars 2020 07:33, Hanno Schwalm notifications@github.com a écrit :

I had a look at the - for me - relevant code. I rather suspect dt_control_delete_images_job_run in control_jobs.c
// remove from disk:
if(duplicates == 1)
{
  // first check for local copies, never delete a file whose original file is not accessible
  if (dt_image_local_copy_reset(imgid))
    goto delete_next_file;

  snprintf(imgidstr, sizeof(imgidstr), "%d", imgid);
  _set_remove_flag(imgidstr);
  dt_image_remove(imgid);

  // there are no further duplicates so we can remove the source data file
  delete_status = delete_file_from_disk(filename, &delete_on_trash_error);
  if (delete_status != _DT_DELETE_STATUS_OK_TO_REMOVE)
    goto delete_next_file;

  // all sidecar files - including left-overs - can be deleted;
  // left-overs can result when previously duplicates have been REMOVED;
  // no need to keep them as the source data file is gone.

  GList *files = dt_image_find_duplicates(filename);

  GList *file_iter = g_list_first(files);
  while(file_iter != NULL)
  {
    delete_status = delete_file_from_disk(file_iter->data, &delete_on_trash_error);
    if (delete_status != _DT_DELETE_STATUS_OK_TO_REMOVE)
      break;
    file_iter = g_list_next(file_iter);
  }

  g_list_free_full(files, g_free);
}
I guess the if (delete_status != _DT_DELETE_STATUS_OK_TO_REMOVE) checks might not be correct so we could still have some sidecars.

On linux this works just right for me, don't know about dt_win_file_trash called by delete_file_from_disk.

BTW the #ifdef _WIN32 sections using dirname seem to be leftovers.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/darktable-org/darktable/issues/4241?email_source=notifications&email_token=AN2X2RROIMSF3PKSXPCEO23RFNHM5A5CNFSM4KRB26FKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENOC2BA#issuecomment-593243396, or unsubscribe https://github.com/notifications/unsubscribe-auth/AN2X2RSJDJ4ER3AREQBAV73RFNHM5ANCNFSM4KRB26FA .

GrahamByrnes commented 4 years ago

Hmm, line 902 free(imgs);

Should that be g_free(imgs); ??? I read that one should pair g-free with g-malloc, free with malloc

But I see that @TurboGit paired

char *tag_a ... g_free(tag_a);

So g_free should be used everywhere?

jenshannoschwalm commented 4 years ago

The free(imgs) is correct as _get_image_list(t) returns a calloc buffer.

This issue is about an orphan xmp file if we delete 'all' (may it be 10 or just 1) developed images from the system. As you described the deletion of the raw file works.

The code i would check - i can't as i have no win system -

In L. 927 the database check seems to work, also the raw file deletion in L.938 seems to be done.

BUT - if delete_status != _DT_DELETE_STATUS_OK_TO_REMOVE the goto delete_next_file would leave sidecars. This could also happen in L.953

I would carefully debug those sections, maybe dt_win_file_trash would explains this to be win specific.

GrahamByrnes commented 4 years ago

Oooooh.... @Mark-64 @jenshannoschwalm Sometimes things stare in your face and you don't see. I put in a bunch of debug fprintf's, and narrowed everything down to the validation of the filename in filepath.c (which is used only by Windows).

What it does in principle is to throw away the two extensions, then starting at the end of the root, the pointer advances until it either finds an '_' or runs up against the start of the filename.

Except: my image files start with an underscore. So for version 0 xmp's, it finds the one at the start, viz: _4022.dng.xmp Then there are no numerals, so it's an invalid filename. Not only windows specific, but camera specific. Some testing to do then...

GrahamByrnes commented 4 years ago

In fact, I think there may be a conceptual problem. The filename passed to win_valid_duplicate_filename is in fact the full filename, despite the pattern-matching that goes on in dt_image_find_duplicates (image.c) just before the #ifdef WIN32 preproc.

So the task for win_valid_duplicate_filename is impossible, without additional constraints on naming: anything is a legitimate version 0 filename.

In order for a decision to be made as to whether foo.dng.xmp is a legitimate xmp filename, we need to know what was used for the image file: then we can cut that from the left and see if what is left is either

.dng.xmp, or
01.dng.xmp (etc).

So unless that is somehow implied by construction of the wpattern string... for the moment I don't get it what the call to filepath adds...

Hints?

jenshannoschwalm commented 4 years ago

Atm i don't really understand what you are hunting for. If we agree on this question:

Why is there a remaining xmp file if we delete the original image?

For me the problem must be inside dt_control_delete_images_job_run

In Line 938 we delete the raw file if there are no duplicates (that seems to be ok also on windows from what you describe).
In Line 939 we check for a correct return value. Have you checked that? If the windows version returns a wrong value the xmp file would not be removed.
Again in the while loop Line 949 ... the delete status might be wrong ...

@peterbud are you sure about the return values from dt_win_file_trash? (I can't check myself as i have no running win system)

GrahamByrnes commented 4 years ago

Yes, the return values are all good.

Consider you have an image file _IMG4722.DNG and an xmp _IMG4722.DNG.xmp

At some stage you send a request to dtwin.c for the duplicate to be validated.by dt_win_file_trash(" IMG4722.DNG.xmp ") It will throw away the end, then start iterating towards the front of the file name looking for an '' Once it finds it, it checks if the following characters were in [0-9]. It it doesn't find it, it declares that it is a valid (version 0) filename.

Except that my camera puts that '_' at the start of the filename, where it is found, and it isn't followed by digits, so it's invalid.

Le mar. 10 mars 2020 à 16:37, Hanno Schwalm notifications@github.com a écrit :

Atm i don't really understand what you are hunting for. If we agree on this question:

Why is there a remaining xmp file if we delete the original image?

For me the problem must be inside dt_control_delete_images_job_run

In Line 938 we delete the raw file if there are no duplicates (that seems to be ok also on windows from what you describe).

In Line 939 we check for a correct return value. Have you checked that? If the windows version returns a wrong value the xmp file would not be removed.

Again in the while loop Line 949 ... the delete status might be wrong ...

@peterbud https://github.com/peterbud are you sure about the return values from dt_win_file_trash? (I can't check myself as i have no running win system)

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/darktable-org/darktable/issues/4241?email_source=notifications&email_token=AN2X2RTGGQGCK6XABLB2FJLRGZNC7A5CNFSM4KRB26FKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEOL5Q7I#issuecomment-597153917, or unsubscribe https://github.com/notifications/unsubscribe-auth/AN2X2RWXRJNVBHREFONDGXDRGZNC7ANCNFSM4KRB26FA .

-- Graham Byrnes Bron (Lyon), France Mes photos: https://500px.com/grahambyrnes

jenshannoschwalm commented 4 years ago

Sorry about my noise, i really missed the important part, the pattern matching with a leading underscore.

I again had a look at your arguments. When reading the doc about wildcard matching and your comment

So "_????" is indeed a wildcard for the "_02" in foo_02.DNG.xmp

i am not so sure about this. The ? matches a single character only. We cant check - as we do on linux for a single char [0-9] - sure but shouldn't it be

static const gchar *glob_patterns[] = { "", "_??", "_???", "_????", NULL }; but i guess you have checked that already

GrahamByrnes commented 4 years ago

That bit works, or it wouldn't handle the duplicates. It's an arcana of windows, ? can be a non-character before a "." In fact the leading '_' seems to be the issue, since disabling it by checking if it's the first char allows everything to work.

Then I got ambitious, unfortunately... in fact there could be an '_' anywhere in the filename and it would cause the version 0 to be rejected.

So I'm trying some other things... and making seg faults. Two steps forwards, 1.96 back...

Le mar. 10 mars 2020 à 20:50, Hanno Schwalm notifications@github.com a écrit :

Sorry about my noise, i really missed the important part, the pattern matching with a leading underscore.

I again had a look at your arguments. When reading the doc about wildcard matching and your comment

So "_????" is indeed a wildcard for the "_02" in foo_02.DNG.xmp

i am not so sure about this. The ? matches a single character only. We cant check - as we do on linux for a single char [0-9] - sure but shouldn't it be

static const gchar *globpatterns[] = { "", "??", "???", "????", NULL }; but i guess you have checked that already

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/darktable-org/darktable/issues/4241?email_source=notifications&email_token=AN2X2RQUJDSZKCPJFK4UN2TRG2KYTA5CNFSM4KRB26FKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEOM4RTQ#issuecomment-597280974, or unsubscribe https://github.com/notifications/unsubscribe-auth/AN2X2RWU62KKMTUBI4SC22TRG2KYTANCNFSM4KRB26FA .

-- Graham Byrnes Bron (Lyon), France Mes photos: https://500px.com/grahambyrnes

jenshannoschwalm commented 4 years ago

BTW maybe you change the title of this issue

jenshannoschwalm commented 4 years ago

Maybe the algorithm is not portable enough as pattern matching differs too much.

What about generating a preliminary list with "filename*xmp" to find all (and maybe a bit more) and remove files that don't "really match"?

GrahamByrnes commented 4 years ago

Yes... maybe tomorrow... I've got a bit of a flu and feeling a little disoriented (still breathing though, no Corona alert).

Le mar. 10 mars 2020 à 21:10, Hanno Schwalm notifications@github.com a écrit :

BTW maybe you change the title of this issue

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/darktable-org/darktable/issues/4241?email_source=notifications&email_token=AN2X2RVFGZO73Z6P56JBWR3RG2NCDA5CNFSM4KRB26FKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEOM6WJI#issuecomment-597289765, or unsubscribe https://github.com/notifications/unsubscribe-auth/AN2X2RV3G6OGIM7NR6BD7HDRG2NCDANCNFSM4KRB26FA .

-- Graham Byrnes Bron (Lyon), France Mes photos: https://500px.com/grahambyrnes

GrahamByrnes commented 4 years ago

Yes, it's quite different... Windows can in principle return something like _img1234_abcd.dng.xmp Also, utf16...

I'm learning lots of stuff :-)

Le mar. 10 mars 2020 à 21:40, Hanno Schwalm notifications@github.com a écrit :

Maybe the algorithm is not portable enough as pattern matching differs too much.

What about generating a preliminary list with "filename*xmp" to find all (and maybe a bit more) and remove files that don't "really match"?

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/darktable-org/darktable/issues/4241?email_source=notifications&email_token=AN2X2RRC4RGLOOV6MAYE26DRG2QT3A5CNFSM4KRB26FKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEONCBHQ#issuecomment-597303454, or unsubscribe https://github.com/notifications/unsubscribe-auth/AN2X2RVXYJSSL6TRMU3J263RG2QT3ANCNFSM4KRB26FA .

-- Graham Byrnes Bron (Lyon), France Mes photos: https://500px.com/grahambyrnes

jenshannoschwalm commented 4 years ago

If you add this

  fprintf(stderr,"\ndt_image_find_duplicates");

  GList *file_iter = g_list_first(files);
  while(file_iter != NULL)
  {
    gchar *xmpfilename = file_iter->data;
    fprintf(stderr,"\n   file '%s'",xmpfilename);
    file_iter = g_list_next(file_iter);
  }

before return files in function dt_image_find_duplicates what do you see when deleting a group?

GrahamByrnes commented 4 years ago

It's fixed :-) I'm just trying to get my head around rebase pull requests...

Supposing I have a master that is identical to darktable-org/daktable master, but has a list of update commits... If I do a pull request for a branch off that, do the string of 10 updates show up (in which case I need to rebase), or are they suppressed since there are no differences in files?

Le jeu. 12 mars 2020 à 07:39, Hanno Schwalm notifications@github.com a écrit :

If you add this

fprintf(stderr,"\ndt_image_find_duplicates");

GList file_iter = g_list_first(files); while(file_iter != NULL) { gchar xmpfilename = file_iter->data; fprintf(stderr,"\n file '%s'",xmpfilename); file_iter = g_list_next(file_iter); }

before return files in function dt_image_find_duplicates what do you see when deleting a group?

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/darktable-org/darktable/issues/4241#issuecomment-598030650, or unsubscribe https://github.com/notifications/unsubscribe-auth/AN2X2RWTQH64ZXRK5LYYAK3RHB7QJANCNFSM4KRB26FA .

-- Graham Byrnes Bron (Lyon), France Mes photos: https://500px.com/grahambyrnes

GrahamByrnes commented 4 years ago

Here is the explanatory PR text for when I get my git together:

There has been a problem for some weeks, where "version zero" xmp files are left behind when the image file is deleted (see #4241).

This is partly a result of Windows having imprecise wildcards: given a file _IMG1234.DNG, the search used to find matching xmp files will return any _IMG1234abcd.DNG with arbitrary characters abcd (of which some or all may be ""). To prevent this, there is a function in win.filepath.c which attempts to detect the "real" duplicates from accidental catches. It does this by starting at the back, jumping the two extensions, then continuing until it finds "". It then checks if the characters removed were digits.

This works for finding non-version-0 duplicates. However, the stopping criterion is reaching the start of the filename... where in the example above, you see there is another "_". Since that one is not followed by digits, it fails.

That could be easily patched, but what if the image file was A_really_long_silly_name.dng ? Or worse, A12_34.DNG which would have a version 0 which looks like a duplicate of A12.DNG.

In fact, without further constraints on the format of the image files, the only reliable way of detecting them is by comparison with the image file name. Since that requires some preparation (removing the preceding path) and need not be recalculated at each lap of the loop over possible duplicates, I moved everything out to filepath.c (with a change of function name and type.

.

Le jeu. 12 mars 2020 à 10:18, Graham Byrnes grahamb29@gmail.com a écrit :

It's fixed :-) I'm just trying to get my head around rebase pull requests...

Supposing I have a master that is identical to darktable-org/daktable master, but has a list of update commits... If I do a pull request for a branch off that, do the string of 10 updates show up (in which case I need to rebase), or are they suppressed since there are no differences in files?

Le jeu. 12 mars 2020 à 07:39, Hanno Schwalm notifications@github.com a écrit :

If you add this

fprintf(stderr,"\ndt_image_find_duplicates");

GList file_iter = g_list_first(files); while(file_iter != NULL) { gchar xmpfilename = file_iter->data; fprintf(stderr,"\n file '%s'",xmpfilename); file_iter = g_list_next(file_iter); }

before return files in function dt_image_find_duplicates what do you see when deleting a group?

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/darktable-org/darktable/issues/4241#issuecomment-598030650, or unsubscribe https://github.com/notifications/unsubscribe-auth/AN2X2RWTQH64ZXRK5LYYAK3RHB7QJANCNFSM4KRB26FA .

-- Graham Byrnes Bron (Lyon), France Mes photos: https://500px.com/grahambyrnes

-- Graham Byrnes Bron (Lyon), France Mes photos: https://500px.com/grahambyrnes

elstoc commented 4 years ago

If only we could name the xmp files (for version 0, for example) A12_34.dng.00.xmp, so the version number is clear and entirely separate from the image filename. Though I don't know how that could be made to work with old edits.

GrahamByrnes commented 4 years ago

It would be logical and reasonable, can't have that :-)

Le jeu. 12 mars 2020 à 11:16, elstoc notifications@github.com a écrit :

If only we could name the xmp files (for version 0, for example) A12_34.dng.00.xmp, so the version number is clear and entirely separate from the filename. Though I don't know how that could be made to work with old edits.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/darktable-org/darktable/issues/4241#issuecomment-598109055, or unsubscribe https://github.com/notifications/unsubscribe-auth/AN2X2RQ3Z356V4F2TX2QCVTRHCZBHANCNFSM4KRB26FA .

-- Graham Byrnes Bron (Lyon), France Mes photos: https://500px.com/grahambyrnes

ptilopteri commented 4 years ago

you are looking toooo hard for something more complicated than need be. How much more clear can it be unless you are viewing it sideways and backwards:

160705_090557_pt1_6805.nef 160705_090557_pt1_6805.nef.xmp 160705_090557_pt1_6805_01.nef.xmp

obviously the xmp with no added ##'s refers to version "0' and the xmp with added "_01" is version "1". UNLESS you have a very odd workflow.

sometimes plain logic must prevail

elstoc commented 4 years ago

And if I have a file named 160705_090557_pt1_6805_01.nef?

GrahamByrnes commented 4 years ago

It should consider 160705_090557_pt1_6805_01.nef .xmp as version zero, and 160705_090557_pt1_6805_01_01.nef.xmp as the first duplicate.

That would be a perverse work flow, but in a sense the image file is the primary key.

Le jeu. 12 mars 2020 à 15:27, elstoc notifications@github.com a écrit :

And if I have a file named 160705_090557_pt1_6805_01.nef?

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/darktable-org/darktable/issues/4241#issuecomment-598216985, or unsubscribe https://github.com/notifications/unsubscribe-auth/AN2X2RUUY7LPRXEFGSRLDZ3RHDWLTANCNFSM4KRB26FA .

-- Graham Byrnes Bron (Lyon), France Mes photos: https://500px.com/grahambyrnes

ptilopteri commented 4 years ago

@elstoc

And if I have a file named 160705_090557_pt1_6805_01.nef? The you have created the first duplicate

@GrahamByrnes

It should consider 160705_090557_pt1_6805_01.nef .xmp as version zero, and 160705_090557_pt1_6805_01_01.nef.xmp as the first duplicate. That would be a perverse work flow, but in a sense the image file is the primary key. Le jeu. 12 mars 2020 à 15:27, elstoc notifications@github.com a écrit :

no, "01" is the first "duplicate". If no duplicate, the xmp does not have ## added. The original xmp file needs no enumeration. You are trying too hard to make something simple, complicated.

GrahamByrnes commented 4 years ago

I don't think you are following the logic. You are asking about the naming convention for sidecar files: it is not me who is proposing to change that. It is coded into dt since the beginning, and works correctly under linux:

a raw file pops out of your camera, it has whatever name it has, excepting only that it terminates with a .dng or other image-file suffix.
the first duplicate is always made by adding an xmp to the end.
the following duplicates are made by removing the image-suffix, adding _01 (_02, or _9999), then re-attaching the suffix and adding a .xmp at the end.

That's it.

My change is simply to allow a windows machine to recognise the xmp's once they exist. It simply does the above steps in reverse, while comparing to the image file. It should result in the same behavior for Windows & linux.

Le jeu. 12 mars 2020 à 15:44, ptilopteri notifications@github.com a écrit :

@elstoc https://github.com/elstoc

And if I have a file named 160705_090557_pt1_6805_01.nef? The you have created the first duplicate

@GrahamByrnes https://github.com/GrahamByrnes

It should consider 160705_090557_pt1_6805_01.nef .xmp as version zero, and 160705_090557_pt1_6805_01_01.nef.xmp as the first duplicate. That would be a perverse work flow, but in a sense the image file is the primary key. Le jeu. 12 mars 2020 à 15:27, elstoc notifications@github.com a écrit :

no, "01" is the first "duplicate". If no duplicate, the xmp does not have ## added. The original xmp file needs no enumeration. You are trying too hard to make something simple, complicated.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/darktable-org/darktable/issues/4241#issuecomment-598227510, or unsubscribe https://github.com/notifications/unsubscribe-auth/AN2X2RTLCP7KOK7RTH3AVFDRHDYNXANCNFSM4KRB26FA .

-- Graham Byrnes Bron (Lyon), France Mes photos: https://500px.com/grahambyrnes

ptilopteri commented 4 years ago

@GrahamByrnes "- the first duplicate is always made by adding an xmp to the end."

no, that is the xmp to match the ORIGINAL the first duplicate has the added enumeraton.

GrahamByrnes commented 4 years ago

Please re-read. It's not a question of aesthetics.

Le jeu. 12 mars 2020 à 16:10, ptilopteri notifications@github.com a écrit :

@GrahamByrnes https://github.com/GrahamByrnes "- the first duplicate is always made by adding an xmp to the end."

no, that is the xmp to match the ORIGINAL the first duplicate has the added enumeraton.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/darktable-org/darktable/issues/4241#issuecomment-598241580, or unsubscribe https://github.com/notifications/unsubscribe-auth/AN2X2RVRK43AZTQMHLYWFNDRHD3OFANCNFSM4KRB26FA .

-- Graham Byrnes Bron (Lyon), France Mes photos: https://500px.com/grahambyrnes

todd-prior commented 4 years ago

You can name duplicates in the duplicate tab. I would love for that name to be a variable that could be incorporated into the xmp file and indeed so it could be added to a string to name exported files…it would help if you were creating a series of duplicates to be able to do this to identify them….so a string for $(VERSION)

For example sometimes I create 4 versions and then delete the three that I don’t like but then I have a file with only one xmp but it is now a _03 or whatever….so all I know is I must have kept the 3rd or 4th duplicate but its not clear how that was different….

Say for example I wanted to tweak WB on three versions ….I settle on one…it would be nice if the file could be exported based on what I named the duplicate…so say WB5500 added to the name and xmp file….those wanting to use a digit could still do it but it would be nice to be able to use the duplicate name……

Just my opinion…

From: GrahamByrnes notifications@github.com Sent: March 12, 2020 6:29 AM To: darktable-org/darktable darktable@noreply.github.com Cc: Prior,Todd priort@mcmaster.ca; Comment comment@noreply.github.com Subject: Re: [darktable-org/darktable] Orphan xmp (#4241)

It would be logical and reasonable, can't have that :-)

Le jeu. 12 mars 2020 à 11:16, elstoc notifications@github.com<mailto:notifications@github.com> a écrit :

If only we could name the xmp files (for version 0, for example) A12_34.dng.00.xmp, so the version number is clear and entirely separate from the filename. Though I don't know how that could be made to work with old edits.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/darktable-org/darktable/issues/4241#issuecomment-598109055, or unsubscribe https://github.com/notifications/unsubscribe-auth/AN2X2RQ3Z356V4F2TX2QCVTRHCZBHANCNFSM4KRB26FA .

-- Graham Byrnes Bron (Lyon), France Mes photos: https://500px.com/grahambyrnes

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/darktable-org/darktable/issues/4241#issuecomment-598114341, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AKS2ES7MTNKJCXM56MISBHLRHC2QFANCNFSM4KRB26FA.

todd-prior commented 4 years ago

You are asking maybe what I just posted….maybe use the name that you can assign duplicates as a variable that can be used in the xmp name and as a variable for file naming on export or copy….

From: elstoc notifications@github.com Sent: March 12, 2020 6:17 AM To: darktable-org/darktable darktable@noreply.github.com Cc: Prior,Todd priort@mcmaster.ca; Comment comment@noreply.github.com Subject: Re: [darktable-org/darktable] Orphan xmp (#4241)

If only we could name the xmp files (for version 0, for example) A12_34.dng.00.xmp, so the version number is clear and entirely separate from the filename. Though I don't know how that could be made to work with old edits.

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/darktable-org/darktable/issues/4241#issuecomment-598109055, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AKS2ESZNEYHVCQZXXJIAJZTRHCZBHANCNFSM4KRB26FA.

elstoc commented 4 years ago

I'm saying (and it's really a bit of an aside to this whole discussion so apologies for that) that, in naming xmp files the way it does, darktable restricts the file names that can be used for the actual images themselves.

I can't have an image named IMG01.cr2 as well as an image called IMG01_01.cr2 because darktable will not be able to distinguish between the xmp for v1 of the first image and v0 of the second image when I come to importing it.

GrahamByrnes commented 4 years ago

Have you tried this? I think it will.

Le jeu. 12 mars 2020 à 16:45, elstoc notifications@github.com a écrit :

I'm saying (and it's really a bit of an aside to this whole discussion so apologies for that) that, in naming xmp files the way it does, darktable restricts the file names that can be used for the actual images themselves.

I can't have an image named IMG01.cr2 as well as an image called IMG01_01.cr2 because darktable will not be able to distinguish between the xmp for v1 of the first image and v0 of the second image when I come to importing it.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/darktable-org/darktable/issues/4241#issuecomment-598260285, or unsubscribe https://github.com/notifications/unsubscribe-auth/AN2X2RV5D2Q7XLSHNQTBFMLRHD7QPANCNFSM4KRB26FA .

-- Graham Byrnes Bron (Lyon), France Mes photos: https://500px.com/grahambyrnes

elstoc commented 4 years ago

I haven't as I'm away from my PC. But how will it name those xmps when it saves them? I'll give it a try when I'm home.

ptilopteri commented 4 years ago

@elstoc but you can, you should get: IMG01.cr2 IMG01.cr2.xmp and IMG01_01.cr2 IMG01_01.cr2.xmp and first dup of this IMG01_01_01.cr2.xmp

ptilopteri commented 4 years ago

and the first IMG01.cr2 IMG01.cr2.xmp IMG01_01.cr2.xmp

ptilopteri commented 4 years ago

er... you are correct

elstoc commented 4 years ago

I've been working on that code quite recently. In the scenario I illustrated it's not possible to have a different xmp file for IMG01.cr2 version 1 and IMG01_01.cr2 version 0. Both images update the same xmp file, and if you create IMG01.cr2 version 1 first, the import of IMG01_01.cr2 uses the v1 xmp on the new image.

jenshannoschwalm commented 4 years ago

@GrahamByrnes isn't this fixed now?

GrahamByrnes commented 4 years ago

Yes... I'll go kill it.

Fixed by #4458

Le sam. 21 mars 2020 à 16:46, Hanno Schwalm notifications@github.com a écrit :

@GrahamByrnes https://github.com/GrahamByrnes isn't this fixed now?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/darktable-org/darktable/issues/4241#issuecomment-602062720, or unsubscribe https://github.com/notifications/unsubscribe-auth/AN2X2RTGZIKZHDJJK6Y3KMLRITONTANCNFSM4KRB26FA .

-- Graham Byrnes Bron (Lyon), France Mes photos: https://500px.com/grahambyrnes

darktable-org / darktable

Orphan xmp #4241

ifdef _WIN32

else