Bug or Feature - v14.3.1 - 'orphaned' sidecars ie remaining after 'delete' are being reused
[ situation]
Mass scanning exercise of some of my 40 or 50yr old stuff.
[recreation]
After trying to brighten up to no good avail the image is deleted from the thumbnail/library area. When scanning (VueScan) the next image a 'numbering scheme hole' is found which is immediately filled (feature) by naming the next image the same (as the newly C1 'deleted' image). C1 then reuses the apparently NOT deleted old edit/sidecar information files to now amend the similarly new scan to the old image's edit... perfect storm.
IMHO deleting the library/thumbnail should logically delete the edit sidecars. OTOH I see the devs' problem, sending the image to the delete folder is easy but similarly attaching the edit sidecars within the delete folder area but keep them ready for associated undeleting is more problematic - particularly across platforms.
So, a bug or feature!? Just a 'heads up' BTW. It's really not a biggie. Those old sidecars were similar to what I would've been using anew or I simply hit the RESET button in C1.
Thoughts?
-
I also have the impression, from recent playing around with one or even two sessions open at the same time, and file movements on system level (Explorer) that indeed some information is held in the session process even when a file is no longer in any of the Session folders, and that this information is written into the .cos file if a certain event occurs.
0 -
I find this behaviour quite okay. Capture One cannot know in which other Sessions pro catalogs the sidecars are used too. Need not even to be on the same computer, could be another network device.
Regards
Ernst0 -
To extend Ernst's observation, if the XMP file is shared between applications in some way it may be dangerous to consider removing it.
This is one of the challenges of synchronisation concepts.
In my opinion, based on some similar experiences to the OP when scanning stuff a few years ago, "filling" names is a feature to be used very carefully - if at all.
Likewise any file naming from digital cameras, especially those that have no way to uniquely identify themselves (by user defineable file name pre-fixes for example) in camera.
When the internal naming system automatically loop around evey 9999 images and more than one camera may be delivering the same file name to the same session (and even more so to a large catalogue) differential naming is important. Hence why applications in the mass market of Mobile Phones where probably 99.999% (?) of all images originate, will normally use date and time as part of the image name (and assume that the internal clock is accurate enough for purpose because it will be synchronised, mostly, quite frequently with a network time control of one type or another.
In either scenario, for a file that may be shared by other applications the "safe" decision would be to leave it where it is and not delete it. That may not be ideal for every user. I suppose one could add some complexity and introduce controls and choices about what to do when actions are taken ... but would everyone understand them? Could they cover every possible requirement that people might dream up. Would the risks be greater than the benefits?
I recall reading an article written by a Synchronisation and security consultant (as claimed) a few years ago which discussed the use of, IIRC, Dropbox (other services are available) to synchronise data between his computers and mobile devices. From memory there was a Desktop machine, a notebook, a phone and a tablet of some sort involved. Plus the on-line storage and backup service.
What he ended up with was a network that shifted vast amounts of data as files and backups changed device by device and, because the entire multi-device data set could not be maintained in "realtime" but he was making changes, additions and deletions on whichever device he happens to be using, the potential for deleted file re-appearing or needed files disappearing was extremely high.
Realising the potential problem and the extent of the problem was based on how he had set up the synchronisation rules he attempted to stop the processing but, by then, the synch schedule meant that to do so would take several days and still leave files deleted, misplaced, etc., etc.
That reminded me of an experience many years ago when an email with a quite large number of recipients was sent in the middle of a Holiday season. This a mail to mainly corporate addresses with some of them having some detailed rules for how emails should be dealt with if they could not be delivered.
Two problems arose. There were a couple of bad addresses so the "Could not be delivered" response was activated. In addition some of the recipients were on holiday and had set up "Out of Office" replies.
So the mail went out and the "Could not be delivered" came back in along with some Out-of-Office responses.
Unfortunately the sending system was set up send everyone in the group a message for any replies that were received.
Most of the "Could not deliver" processes were automatically set up to "try again", FOr the first hour that was attempted every 5 minutes or so. About every 15 minutes it more than one hour had elapsed and so on until after 24 hours I think it dropped to once a day for 30 days.
The resulting mail storm overloaded several systems and caused enormous backlogs. Some recipients were able to take action and with the help of their IT department , start to break the chain but in many cases there was nothing logical that could be done, especially when the "could not deliver" messages were coming from various nodes of the email service providers rather than end-user businesses.
Eventually the number of messages reduced and disappeared but it took several months before the end of the "long tail" of bouncing messages finally ran out of time.
Hopefully in the past 30 years or so, emails systems have developed methods of spotting such problems and eliminating them. Preferably without breaking some other aspect of functionality and security.
1 -
@ SFA - Interesting thoughts - my thanks.
I've never found a way of stopping the 'filling' done by VueScan. Seems to be part of its auto-incrementing design which is necessarily in use during batch scanning.
What I have decided to do, as the man-in-the-middle, is amend the VueScan naming template's scope (by say an hour) following each C1 library/thumbnail delete event. That more safely and fully appeases the design of C1's delete/undelete mechanism while also supports VueScan's auto-numeration of batches. In the OP I said it was a bit of a perfect storm. This thread's scenario falls foul of a number of 'helper' mechanisms that don't quite mesh. As MITM I will amend my workflow to fix it:-)
My cameras and scanner are both sources of images. However the design of the formers' BIOS pretty much always produces a reasonably uniquely named file (for all the obvious reasons). The latter does it by the software bridge and its native auto-numeration feature enables fully automated batches - for instance nearly an hour to complete a run with a fully populated 35mm skeleton carrier (high res). My amended workflow above is a perfectly acceptable workaround.
I keep as much as is possible on site so I really don't incur issues with things like sync or clouds!
As for your email storm, in the past 30 years or so, yes. My own email server's various daemons and algorithms pretty much do their stuff nicely. The stopping of a 'bounce of a bounce' was implemented ...more years ago than I can reliably remember:-/
Good to talk to you all and thank you for your various thoughts. The thread title asked a question, the answer I believe is "Both ...depends on your POV". My amended workflow workaround will satisfy the apparent issue. Cheers:-)
0
Post is closed for comments.
Comments
4 comments