P: Store the xmp metadata outside DNG, jpeg etc file to be backup efficient

DNG files aside, I still wish there was a way to make changes to a file’s rating or flag, without Lightroom changing the files CREATION DATE. I understand that it will write the changes in a rating to the jpeg file (although I am not happy about that) which changes modification date, but why does Lightroom change the creation date as well? That makes no sense! Interestingly, Lightroom does not change the creation date of an xmp file when I make a rating change, only the modification date.

Why can’t Lightroom give us better choices in settings to including not write changes in ratings, flags, etc. to jpegs, while still allowing changes made in Lightroom (or Camera Raw) to raw files to be recorded to the corresponding xmp files?

Lightroom should behave nicely with common and ubiquitous consumer-level backup solutions.  Writing metadata changes & develop settings into a DNG that is 20-100 MB per image is not good design and does not play well with others.

Lightroom and the DNG spec do not exist in a vacuum nor in a perfect world.  It's time Adobe create an option for those who want XMP sidecars with DNGs that aren't re-written every time they're edited.

John, I don't know what environment you work in, but I would suspect many users here are lucky to be able to run simple NAS hardware and at least some are using arrays of HDDs. The simplest implementation involves using OS-based tools that are available for Windows and Macs that have a proven track record and do not create custom files.

For me, it is important that all the backups are a replica of the tree and accessible to the individual file level without special software.

That works for NAS units and local HDDs and is mimicked in Backblaze and Dropbox.

Most OS-level tools (unlike Backblaze and Dropbox) that I am aware of do not do block level compare/copy, but rather just copy the entire file.

But besides that, I am not pleased at risking my original archival "negative" files being written to on a regular basis.

I couldn't care less what your current backup solution looks like, but it's clearly not optimized for DNG if you are repetitively backing up files. Flabby backup procedures aren't a reason for adding what isn't just a simple option but one which has other consequences, since LR and other apps will no longer know whether to prefer embedded or sidecar metadata. And while development resources may or may not be a zero-sum game, time spent on an unnecessary option will not be available to work on things one does appreciate. So no, no option thank you.

Note that LR uses .xmp sidecars for HEIF files (what Apple calls HEIC), even though the format specifies where to store EXIF and XMP metadata inside the files.

"I am not suggesting a less robust model but one which covers all images and all the work."

You have no idea how my current backup solution looks like, what my workflow looks like, how I have Lightroom set up, what other backup needs and software I have, what kind of a system I'm even running etc. pp. You are hardly in a position to judge what would be a good backup solution for me. And neither for many other users out there. So please respect that while you may be perfectly content with how Lightroom interoperates with your preferred backup method, for others it is a constant headache—and one that has a very easy solution, if only Adobe chose to provide a very simple preference setting that would have absolutely no effect on users like you.

And yes, "leave it disabled" is a perfectly sensible argument. That's actually the whole point of options—they provide options! They are there so the user can choose based on his specific needs. I could choose to enable the option to accomodate my needs, you could choose not to enable it to accomodate yours. That would be a very satisfactory solution, unlike the current state that allows your needs to be met, but not mine.

Just because you dislike it, doesn't mean everyone dislikes it. While I've had no problems with copying files recently, I did lose a copy of a WAV file that was copied because metadata was changed and it somehow became truncated. I fortunately found a copy on an older backup.

Let's look at the universe:
Proprietary camera raw: Has sidecar
Standard TIF and JPG files: no sidecar
DNG: no sidecar

What if TIF and JPG and DNG files had side cars? The Adobe products would see them and look there for the metadata.

One of my major concerns is actually about JPGs because some users/devices originate in JPGs so those are your "negatives." It was actually that which caused me to not propagate updates to the backup NAS.

It's not the developers' prerogative - it's ours. I am not suggesting a less robust model but one which covers all images and all the work. The catalogued DNG can be written as many times as one wants, and doesn't need repetitive backup that only partially contains your work.

As with any proposal, I can't buy the "leave it disabled" line. The development resources would have been spent on something one dislikes. But it's more than dislike here. As David Converse pointed out, one can only imagine the incompatibility and confusion that this idea would introduce.

The good news is that many cloud services do incremental backups if that is your method of backing up.

I also keep two NAS units. Updates are made to the main NAS, but for certain file types (WAV, TIFF, JPG) updates are not propagated to the backup NAS. Deletes are not propagated to the backup NAS. Updates and deletes are propagated to the backup machine that feeds Backblaze.

"Changes are always written to the catalog, even if you have this option turned on."

That is correct, and I didn't mean to imply otherwise. (Also, see my correction concerning locked DNG files above.)