C1 v11 can lose edits moving internally

[NN635976380434502912UL]

I know that C1 docs recommend moving folders from one drive to another internally in the Library panel. So I was moving them, one at a time (sure wish I could select several at once). Some of the folders popped up a message warning about moving Thumbs.db and no matter what choice I made (move or don't move) it still went through the process of importing the moved images as if they were brand new and they were no longer connected to their edits! YIKES.

This didn't happen if a thumbs.db file wasn't in the folder. It went as expected.

Turns out FastStone Imageviewer leaves a thumbs.db file in the folder. It appears that C1 is using a Windows Explorer call to actually move the files when you drag and drop from within C1. The reason I suspect this is that the warning dialog about moving thumbs.db is the same you get if you copy/move folders in Windows Explorer. My hypothesis is that this 'unexpected interruption' confuses C1 and instead of linking to the moved files it performs an import.

The way I got out of this jam was to find a recent catalogue backup and then use 'locate' to relink the files in the moved folders. That worked. Now I believe moving the folders OUTSIDE of C1 (with C1 shutdown) and then relocating the folder is the safer method.

Has anyone else seen this behavior? What is your preferred way to move folders to keep them linked?

[NNN636735230673236717]

As you pointed out the Thumbs.db are files created by image viewer application that have nothing to do with C1 and in a way makes it difficult to work in C1 as you described. I suspect that Thumbs.db are files that your image viewer creates to store miniature versions of picture files in that directory to display filmstrip style catalog of what is in the directory without having to actually read each picture and create a little thumb view of it. These files are there for speed, nothing else. If the file's attribute is marked as 'Hidden' or 'System' the operating system will warn you that you are moving system files, hence the popup message.
Since these files have nothing to do with C1 and will be regenerated as soon as you scan that directory with 'FastStone ' anyway, then there is no harm in deleting them prior to moving your images using C1 recommended method.
The quickest method I know would be to open explorer to the root directory of your images and in search window type "Thumbs.db" and press Enter. In just a second or two you will get a list of all Thumbs.db files in their directories down from where you started the search. Click on any one of them and then press [CTRL]+[A] to select them all. If you press [SHIFT]+[DEL] it will prompt you if you want to permanently delete them: select YES, there is no good reason to move them first to Recycle Bin and then delete them again later.



Or if this is too many steps then you can write a small Batch/PowerShell file that you execute just prior to you moving the files.

EDIT: After reading it again: If the problem is the attribute of the file, then you can write a batch file to change/reset the attributes of those files and the system will not complain about it when moving them.

[NN635976380434502912UL]

Thanks for the suggestion Rob.

Have you ever seen problems with moving folders outside C1 (with it shutdown) and then using locate to relink? Moving using Windows seems more flexible that using C1.

While deleting the files ahead of time prevents the problem, it is really easy to forget to do this and then your catalogue is off and you have to fall back to an earlier one, possibly losing recebt edits. My preference would be for C1 to be fixed to avoid this problem.

I hope this topic warns others so they don't create the mess I did.... (or C1 did .

[IanL]

My preference would be for C1 to be fixed to avoid this problem.

Totally agree. Rob has listed a few work arounds. I suggest reporting this to C1 support and point to this thread so they see you already have work arounds - just need the bug log.

[NN635976380434502912UL]

I did pass it along to support and they jumped on it. I just posted the logs to them.

[ChrisM]

I am not sure if this problem is in any way related, but moving folders inside CO1 appears to be susceptible to causing catalogue database corruption, whilst re-linking to folders that were moved outside of the CO1 app, seems a safer bet right now. Where this problem of database corruption also shows, is when using the catalogue cross platform on both Windows and MacOS: folders may arbitrarily show up empty, all original images having disappeared from that folder after moving it inside of CO1 on e.g. a Windows PC, and then opening the same cataloge on a MacOS computer and re-linking the folder. The re-linking is not the problem, but all images may be lost from the folder, and all edits to these images ending up without the original source image, whilst these source images are still physically there in the folder.
This indicates, that changes to the catalogue folder structure and contents when moving folders around (or e.g. re-naming them) inside the CO1 app, are not processed/written correctly into the CO1 catalogue database in certain circumstances.

Chris

[IanS]

I know that C1 docs recommend moving folders from one drive to another internally in the Library panel. So I was moving them, one at a time (sure wish I could select several at once). Some of the folders popped up a message warning about moving Thumbs.db and no matter what choice I made (move or don't move) it still went through the process of importing the moved images as if they were brand new and they were no longer connected to their edits! YIKES.

This didn't happen if a thumbs.db file wasn't in the folder. It went as expected.

Turns out FastStone Imageviewer leaves a thumbs.db file in the folder. It appears that C1 is using a Windows Explorer call to actually move the files when you drag and drop from within C1. The reason I suspect this is that the warning dialog about moving thumbs.db is the same you get if you copy/move folders in Windows Explorer. My hypothesis is that this 'unexpected interruption' confuses C1 and instead of linking to the moved files it performs an import.

The way I got out of this jam was to find a recent catalogue backup and then use 'locate' to relink the files in the moved folders. That worked. Now I believe moving the folders OUTSIDE of C1 (with C1 shutdown) and then relocating the folder is the safer method.

Has anyone else seen this behavior? What is your preferred way to move folders to keep them linked?

Why generate the thumbs.db file at all? Simply tick the box in settings to use the Faststone database file.
Ian

[SFA]

I know that C1 docs recommend moving folders from one drive to another internally in the Library panel. So I was moving them, one at a time (sure wish I could select several at once). Some of the folders popped up a message warning about moving Thumbs.db and no matter what choice I made (move or don't move) it still went through the process of importing the moved images as if they were brand new and they were no longer connected to their edits! YIKES.

This didn't happen if a thumbs.db file wasn't in the folder. It went as expected.

Turns out FastStone Imageviewer leaves a thumbs.db file in the folder. It appears that C1 is using a Windows Explorer call to actually move the files when you drag and drop from within C1. The reason I suspect this is that the warning dialog about moving thumbs.db is the same you get if you copy/move folders in Windows Explorer. My hypothesis is that this 'unexpected interruption' confuses C1 and instead of linking to the moved files it performs an import.

The way I got out of this jam was to find a recent catalogue backup and then use 'locate' to relink the files in the moved folders. That worked. Now I believe moving the folders OUTSIDE of C1 (with C1 shutdown) and then relocating the folder is the safer method.

Has anyone else seen this behavior? What is your preferred way to move folders to keep them linked?

Why generate the thumbs.db file at all? Simply tick the box in settings to use the Faststone database file.
Ian

It occurs to me that this whole issue is a non-problem.

I use FastStone and I have never seen any thumbs.db files. That said I would assume Capture One can be tweaked to make it ignore such files and eliminate the perceived difficulty.


Grant