Using Google Translate (I am struggling to learn French, no way will I take
on German also!), I think I have a pretty good idea on how you did it.
Nice solution. Not sure which way I will go, from overkill using Tripwire,
to a custom shell script or a Java/.Net application. I just know I am not
going to try and learn Lua.

Tim

On Thu, Aug 30, 2018 at 2:04 AM, Bernhard <darkta...@intervalsignals.org>
wrote:

>
>
> Timothy Spear schrieb am 12.08.2018 um 18:42:
>
>> The primary reason I have converted from CR2 and JPEG to DNG was for the
>> inherit hash embedded in the file which can help prevent/notify you of bit
>> rot. Since I have previously experience with bit rot I consider this worth
>> it.
>>
>> Which reminds me, I need to put in a new ticket issue to suggest a
>> validation function to dt which will store a hash for both the XMP and the
>> original image, and can run in a background process.
>>
>>
> That's what I am doing currently with my .NEF and .ORF files:
> https://www.bilddateien.de/fotografie/bildbearbeitung/foto-backup.html
>
> Translation of the important part:
>
>> Checking data consistency
>> What does "data consistency check" mean?
>>
>> For digital data, so-called checksums can be determined by mathematical
>> methods, which represent a kind of "fingerprint" for a file. Changing the
>> file, either by processing or by a data error that has crept in over time,
>> results in a change to the checksum.
>>
>> If you now determine their respective checksums for all files to be
>> backed up and save them, you can check at any time later whether the files
>> are still in their original state. To do this, the checksums are determined
>> again and compared with the values originally calculated and saved.
>> Deviations indicate file errors.
>> prerequisites
>>
>> On the basis of the "non destructive imaging" technique described above,
>> the consistency check results:
>>
>> There are a lot of files in the camera raw formats, but possibly also
>> uncompressed in.tif, which take over the function of the analog "negative"
>> or "slide" as original files, can only be read and should therefore not
>> change anymore.
>> These - and only these - are the subject of the test!
>> And then there are at least as many of these xml files (2 edit versions
>> of the same image give 1 raw file and two xml files) in the same folders,
>> whose characteristic is the change.
>> Pictures and associated xml-files are typically located in year folders
>> and there in subordinate project folders.
>>
>> The check (both the original generation of the checksums and the
>> subsequent comparisons) should be performed automatically by software.
>> Such a software results in a requirement profile:
>>
>>     Program with GUI (graphical user interface - no command line stress)
>>     Recursive creation and checking in directory trees (subdirectories
>> are also searched)
>>     Filtering of unwanted file types (here in the concrete example: xmp
>> (of Darktable), pp3 (of RawTherapee), ...)
>>     possibly different hash functions (mathematical methods for checksum
>> determination) for selection (crc32 or md5)
>>     if possible cross-platform software (there are versions for Windows
>> as well as Linux)
>>
>> An example of a suitable software is Checksum Control.
>>
>> Translated with www.DeepL.com/Translator
>>
>
> --
>
> regards
> Bernhard
>
> https://www.bilddateien.de
>
> ____________________________________________________________
> ________________
> darktable user mailing list
> to unsubscribe send a mail to darktable-user+unsubscribe@lis
> ts.darktable.org
>
>

____________________________________________________________________________
darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Reply via email to