IM3 properties to IM5 attributes

[DigPeter]

I have just tried this fo the first time.  The export from IM3 worked OK.  Because the IM5 files are copies of the originals and held in different folders, I used the checksum method to import.  The results are very patchy.  Some files' properties show in attributes, but many others do not.  The files are all exact copies and have data in atleast Title.  Is this expected behaviour?

[Mario]

Certainly not.
I added this feature several month ago and I don't call bug reports. I tested this here just recently for some of my old IM3 databases and it worked.
As usual, the log file would help (see How to report bugs) because it may contain error messages or warnings encountered during the import.

Also, for one of the files for which properties could not be mapped, compare the check sum shown in IMatch 5 with the check sum shown in IMatch3, you can use the variable {File.CRC.Hex} in IMatch 5, e.g. in the App Panel. It must match the check sum in the property schema file.

[DigPeter]

Mario
I tried the import on checksum again.  This time I can find no attributes, but I have not inspected all files.

The attached zip contains a log file, an image with no attribu and an extract from the IM3 export file for the image.  I could not get the checksum in IM5 - too advanced for me.  Perhaps you can get it from the image.

[attachment deleted by admin]

[thrinn]

I could not get the checksum in IM5 - too advanced for me.

You can access the CRC e.g. in the VarToy App using the following expression:

Code Select Expand

{File.CRC|cast:hex}

[Mario]

Open the App Panel (View > Panels > App Panel).
In the App panel, select the app named VarToy from the drop-down list at the top.
Then copy/paste this variable into the upper edit window:

{File.CRC.Hex}



The value of the variable is displayed in the lower box. The VarToy App is a great feature to learn about variables.



[attachment deleted by admin]

[Mario]

Thanks for the sample file.
I have added the file to an IMatch 5 database. The calculated check-sum is

F6707CE3.

The check-sum in the property schema is:

FB890CD6

The check-sums are not identical. This explains why IMatch 5 cannot map the file.

I then added your sample file to an IMatch 3 database. I get the same check sum as IMatch 5!

<Row>
<URI>file://F:/bugtrack/community/1465/Armenia20222.jpg</URI>
<CRC>F6707CE3</CRC>
...


So when I add the file to IMatch 3 and export it, the check-sum is OK and can be mapped by IMatch 5.
I don't know why you get a different check-sum. Can you please select the folder containing this file in IMatch 3 and then run the Database Wizard to rescan the folder? Please set the option "force update" to tell IMatch to drop all data and re-create everything from scratch. Then export the property schema again and see if you get a different check-sum.

[DigPeter]

So when I add the file to IMatch 3 and export it, the check-sum is OK and can be mapped by IMatch 5.
I don't know why you get a different check-sum. Can you please select the folder containing this file in IMatch 3 and then run the Database Wizard to rescan the folder? Please set the option "force update" to tell IMatch to drop all data and re-create everything from scratch. Then export the property schema again and see if you get a different check-sum.

I will do this.  But perhaps the explanation is that the files in IM5 are copies of the files in IM3.  Could something happen with the checksum in the copy process?

[Mario]

A copy of a file should be binary identical and thus give the same check-sum. Unless your copies are somehow modified, the check-sum should match.
Did you write-back metadata to the files in IMatch 5 perhaps?

[DigPeter]

Did you write-back metadata to the files in IMatch 5 perhaps?

Yes and a whole load other stuff "testing" your great product 

[DigPeter]

Thanks for the sample file.
I have added the file to an IMatch 5 database. The calculated check-sum is

F6707CE3.

The check-sum in the property schema is:

FB890CD6

The check-sums are not identical. This explains why IMatch 5 cannot map the file.

I then added your sample file to an IMatch 3 database. I get the same check sum as IMatch 5!

<Row>
<URI>file://F:/bugtrack/community/1465/Armenia20222.jpg</URI>
<CRC>F6707CE3</CRC>
...


So when I add the file to IMatch 3 and export it, the check-sum is OK and can be mapped by IMatch 5.
I don't know why you get a different check-sum. Can you please select the folder containing this file in IMatch 3 and then run the Database Wizard to rescan the folder? Please set the option "force update" to tell IMatch to drop all data and re-create everything from scratch. Then export the property schema again and see if you get a different check-sum.

Have done this and checksum is same - <CRC>FB890CD6</CRC>  I guess that the metadata write back is the reason.

[DigPeter]

Another thought - I had done some work with metadata with those files in IM3, since they were copied into the IM5 database.

[DigPeter]

I have just created a new IM5 database with new copies of the IM3 files.  IM3 properties have migrated to Attributes successfully using checksum.  Is the lesson not to mess with metadata before importing Attributes?

[Mario]

I have just created a new IM5 database with new copies of the IM3 files.  IM3 properties have migrated to Attributes successfully using checksum.  Is the lesson not to mess with metadata before importing Attributes?

Correct! The check-sum represents the binary contents of a file. When you copy a file and then change the metadata in the copy, the copy is no longer binary identical to the original file. IMatch will (and has to!) calculate different check-sums for both files.