> On Feb 14, 2022, at 11:15 PM, Godfrey DiGiorgi <[email protected]> wrote: > > > It is far more sensible to place the files where you want them to reside in > the working file repository, either before or while using the import process > in LR, rather than moving them from one place to another with the multiple > levels of indirection implied while LR is managing them and all the attendant > database parameters it is creating about them. The difference in operational > performance is insignificant, and risky as you've discovered. It may even > ultimately be lower performance, even if successful.
The *only* level of indirection here is how one gets to my home directory. One of the major points of lightroom is to organize my photos and I am specifically using it to organize my photos into a logical, and sensible directory tree. > > Remember that a parameter based editing app like Lightroom is basically > treating the original file repository as read only and does not write to the > original files unless specific operations are enabled that force it to; the > default configuration never sets those options. Reads are much faster than > writes. Put the files in their final resting positions and put the LR catalog > and thus its temporary files (.LRCAT, .LRDATA, and .LRCAT-DATA which it both > reads AND writes frequently) on the SSD for best performance. This has always > been the best LR configuration for performance, based on my empirical testing > of LR configurations over the past 15+ years. Does your testing involve all use cases? Do you often come back from excursions with thousands of files to sort and process? My impression is that you tend to shoot many fewer frames of much more static subjects than I do. When I’m shooting film, I do as well. I could see that apart reading the files off the card, or apart from starting lightroom when loading all of the files into memory being able to seek to them and read them more quickly is less important, particularly when there are many fewer of them. > > Your archives should be completely separate from LR (or any other app's other > than the backup software itself) working operations. An archive should be a > repository where things are stored, not manipulated in use — essentially > static data, mirrored by backup software only to reflect changes/additions > from the working repositories of the data they are archives of. Anything else > is poor backup policy and implementation. Yes, that is the archive. I read the files off the card onto the SSD. I sort the files into a logical directory heirarchy with the directories named by both date and subject, with further sorting by things like subject, panorama collection and such. Once everything is in place, no longer being moved around I then archive it and make the long term backups. I realize that some people feel that it’s best to let lightroom just put every photo in one giant flat directory, but I don’t necessarily intend to always use Lightroom so it is important to me that I can find photographs without relying on a database that I will lose access to as soon as I stop paying the monthly ransom, or lightroom stops working on my computer. As you may have noticed, I did find a workaround to the bug, but I do consider it important to warn others of the potential hazard. Some people might even make the argument that if Apple does provide the basic posix set of commands, they should work properly. -- Larry Colen [email protected] -- %(real_name)s Pentax-Discuss Mail List To unsubscribe send an email to [email protected] to UNSUBSCRIBE from the PDML, please visit the link directly above and follow the directions.
