Feature request: Missing "copy to catalog" command

[Sedat]

I'm wondering why is there only a "move to" catalog command, and not an additional "copy to catalog" command.

 

I can imagine, that such a copy command could be usefull sometimes.

For instance I would then be able to create a sort of "sub" catalogs of certain selected images out of the master catalog but without loosing the files from the master.

[Uwe]

Hello Rawshooter,

 

there is a "Copy" function. Select the item(s) in the source catalog and press CTRL-C. Then go to the destination catalog and press CTRL-V. Now the Import Dialog appears etc...

 

But: there is an error in the Import Dialog:

The DateTimeOriginal of the item I've selected is: 20131002_152939. But in the Import Dialog appears the File Creation Date, in this case 05.10.2013. There should be the DateTimeOriginal like in the "native" Import Dialog.

 

 

Regards, Uwe

[Sedat]

Hi Uwe,

 

yes this copy and paste works but the problem is, that it does an import and if the desired source files are not on sync with the catalog, you will most likely get inconstistent data in the target catalog.

 

As for the Datetime missmatch, I could not reproduce that. It shows the same correct creation date.

[Uwe]

Hi Rawshooter,

 

what do you expect from a copy function? From my point of view: it has to be an import in the target catalog.

What do you mean: "...not on synch..."?

My point of view:

1. the copy should be a "physical" copy of the source files from the source folder to the destination folder. I'm still not satisfied with the design of the current "Move to" function but this was and should be discussed in another post.

2. if there is a "hanging synch" because of "synch off" status in the source catalog the user should get an information either to continue with "wrong/metadata not synchronized between catalog/item and file" or to "cancel" the copy process. Then he can synchronize the files and the items of the source catalog and can start the copy again.

The status "synch=off" in the target catalog should not to be taken into consideration. The import action of the copy function writes the metadata from the files that were copied to the target catalog.

 

Regards, Uwe

[Sedat]

what do you expect from a copy function?

 

The same as the move command does. Except deleting the source element afterwards. That's all.

 

From my point of view: it has to be an import in the target catalog.

Why that? The move command doesn't need a re-import so the copy command should just do the same.

 

What do you mean: "...not on synch..."?

The metadata stored in the catalog isn't allways necessarily the same as the metadata in the file.

 

1. the copy should be a "physical" copy of the source files from the source folder to the destination folder.

 

I think you need to distinguish between "physical" file operations with the file explorer and copy or move (database) elements from one catalog to another. These are two different tasks.

[Uwe]

Hello,

my summary:

To make the explanation easy I'll use catalog_01 on disk_01 for the source catalog and catalog_02 and disk_02 for the destination catalog.

 

1. the "Move to" doesn't delete the source element from disk_01. It removes the item from the source catalog_01 and the file itself remains on its place in the folder on the disk_01.

2. The "moved" item is imported in the destination catalog_02 without any interaction by the user by reference/link to its original place in the folder on the disk_01. That means: the file is not "moved" as it happens with the Windows "Move": copy the file to its new place and delete it from the old place.

3. If you now make a rescan folder in your source catalog_01 on disk_01 the "moved" item is back in your source catalog_01. Now you have the item in catalog_01 and catalog_02 but it's only once on the disk_01. You can imagine what happens when you change someting in the item in catalog_02 and catalog_01. Who wins this race?

4. Back to the Copy function: To define the destination folder in catalog_02 on disk_02 one needs an Import Dialog for the copy function. Please take into consideration how the "Move to" works: it doesn't "moves the file", it creates a new link from the catalog_02 on disk_02 to the physical place of the file on disk_01. Therefore the "move to" doesn't need an Import dialog. Maybe one can add a Dialog Window to define the metadata which should be "transferred" to destination catalog_02 on disk_02. But this would be a horror scenario because of point 3.

5. To decide which metadata of the file should be copied in the destination catalog_02 one needs an Dialog Window/Copy Preset.

6. Yes, one has to distinguish between operations with items in the database and the files on disk. But you can't have an isolated view to both objects. At any time you have to decide which metadata are the winner: the metadata of the file on disk or the metadata of the item in the catalog and where do you store the file and how many "versions" (not in the meaning of Daminion version Control) do you have on different places in different catalogs.

 

Regards, Uwe

[Sedat]

I see your point Uwe.

One master file physically on disc, referenced into two different catalogs. One could possibly overwrite the others settings. Right?

 

Well, is that a problem? Everyone can overwrite the metadata in the file. It could be simply done by a RAW converter for instance. But in any way, the settings in the catalogs are always left untouched by others. That's why these are always my "master" settings. After the file is once imported, I don't care about the settings in the file anymore.

Even when I'm doing an export, Daminion is taking the metadata always from the catalog and not from the file itself.

When I'm changing the metadata for a certain element within one catalog, these changes are of course not reflected on the other catalog but who cares? The other catalog could have a different task and or other needs for describing the images. That's why I copied the file into a different catalog.

 

Another thing is, if files where physically removed or deleted within one catalog, then of course, these files will be missed (unreferenced) in the other catalog. But this external deletion or removing can also happen, if one removes or deletes files with the windows explorer. But for those occasions, we have the "relink item" option in Daminion. So even here I see no problems having many references to one file on disc.

 

I mean, you can't avoid such duplicated elements in any way, because everyone can easily create two catalogs and import the same files into them.