Moving, Deleting and Renaming can all be done programatically outside of LR with or withour LR file utilities; however, none of these will show the changes inside the catalog. Very frustrating but I can't find a workaround that doesn't require re-synching the folders which isn't real practicle. Maybe someone has found a way to fool LR into these tasks inside the catalog as well as on the operating system - I am all ears ...
Using catalog:addPhoto you could semi-automate re-adding the renamed files - moving the old files to a collection so the user can delete them (there is no catalog:removePhoto method). Just doing that much would suffer the same problem as doing it manually since the ratings and labels, etc. don't carry over, however as long as the plugin was willing to read whatever it can from the originals (stuff not in xmp that is) and write it to the new targets, the only thing I can think of that would be lost is the edit history list (and with the correct marketing skills - that could be billed as a feature ).
Although a bit klugy, this may be perfectly acceptable to those facing more grizzly prospects...
I use catalog:addPhoto() frequently for interim scan processing for noise removal and metadata stuffing. I think what you are saying is that:
1. An export to Original routine could be written for a group of images;
2. After the export routine makes a copy, but before the copy is added to the catalog, items such as capture time, make and model (not available for writing in LR) can be added by something like exiftool;
3. The original image is added to a collection called "DeleteWheneverYouGetaMoment";
4. The copy is added to the catalog; and
5. Whenever you get a moment you can select the collection and delete from catalog and from disk.
Just doing that much would suffer the same problem as doing it manually since the ratings and labels, etc. don't carry over, however as long as the plugin was willing to read whatever it can from the originals (stuff not in xmp that is) and write it to the new targets, the only thing I can think of that would be lost is the edit history list
I wasn't aware that these items didn't cary over. Is this for all exports or just "Original"? Is this for LR2 and LR3?
Don't know if there is a big market for this kind of routine - you and I may be the only two
Well, counting you and me, there's gotta be at least 3 people who would want this .
I stand corrected - Lr3 has been enhanced to support ratings and labels in xmp! - Thus, at least those two things are not lost anymore.
But, I think you've got the right idea, to reiterate:
For the purpose of folder restructuring and photo renaming, I'd think just a plugin extra that makes a copy wherever with whatever new name which is then added back to the catalog would preserve most everything (adding the original to the "delete" collection).
Tossing in a call to exiftool somewhere would allow you to do some more stuff... (never done that yet - but I can imagine).
I'm not sure what exporting to original buys you versus just handling everything without an export (e.g. plugin extra), hmmm...(?)
PS - Actually there has been several people chiming in about wanting a filename search and replace and such stuff. Actually, I wanted it two years ago when I was trying to integrate my entire varied collection into Lightroom, but since I now have unique names for all my photos and folder/filenaming conventions that are still working for me, I haven't needed it since. I would guess its one of those things that the average user finds themselves needing every few years or so, at most, although I guess there are some folk who may want it as a regular part of their workflow - dunno.
Virtual copies may be a bother...(?) - I wish those were represented in xmp which could then be imported too. More specifically, I wish they were handled just like real photos in every way, with the single exception that they share the source of the real copy. Or an even better way of looking at it: I wish real copies were handled just like virtual copies: all copies (real and virtual no longer having a distinction) being represented as a set of settings and such and a pointer to a source file - now we're talking... The virtual copy was sort of an add-on I think as opposed to really being thought out and designed in from scratch...