manage XMP sidecar files

[esq4]

This is a concept for a solution to synchronize editing across different OS (for #18253).
It extends crawler.c functionality and allows additional interactive tracking of the following changes: appearance of new duplicates, deletion of individual duplicates, deletion of the original images.
It looks like this:

Removing unnecessary images and adding new ones is not supported: for this purpose there are corresponding modules "import" and "actions on selection".

[esq4]

I have approximately implemented this #18253 (comment) idea.
After the first full synchronization of the storage and db, the time is stored in darktablerc as the db_synchronized parameter.
A file [directory name].dt is created in each storage directory corresponding to a film roll. It is overwritten every time an action is taken on any XMP file in this film roll. The crawler compares the modification time of .dt file with db_synchronized and determines whether the images in this film roll were edited since the last full synch.

[wpferguson]

A file [directory name].dt is created in each storage directory

I'm not sure that's going to sit will with the "after edit" crowd who don't want any extra files in the picture directory...

Will this cause any issues if the database base gets destroyed and everything has to be reimported?

[esq4]

I'm not sure that's going to sit will with the "after edit" crowd who don't want any extra files in the picture directory...

The size of these files is 0 bytes. ¯\_(ツ)_/¯

Will this cause any issues if the database base gets destroyed and everything has to be reimported?

When importing images into a new db, the import_timestamp in each XMP file will be updated and XMP files will be overwritten. The modification time of the .dt file will be updated along with them. Once the storage is connected to another system, the program will require synchronization for these imported images (of course, if the film roll is already in the db).

[TurboGit]

The size of these files is 0 bytes. ¯_(ツ)_/¯

The size if not the issue here, many people wan't dt to not create a single file in their directories.

Also we have a DB some maybe better to keep this timestamp inside it, no? I haven't looked at the proposal here (I'm not convinced) but a possible solution would be to add a field in table film_rolls maybe.

[esq4]

Fixed deletion tracking.

[esq4]

Also we have a DB some maybe better to keep this timestamp inside it, no? I haven't looked at the proposal here (I'm not convinced) but a possible solution would be to add a field in table film_rolls maybe.

We have two (or more) isolated DBs and the XMP files in the storage serve as a communication channel for synchronizing these DBs. And .dt files allow us to reduce the amount of change scanning.

The size if not the issue here, many people wan't dt to not create a single file in their directories.

That is, they do not use XMP files and do not enable their checking at startup. This means that an extra file will not be created.