Wrong files detected as versions

Started by CMinguell, April 25, 2017, 07:28:37 PM

Previous topic - Next topic

CMinguell

Hi all,

I have a problem with versioning. Usually it works well, but I had two times the same behaviour indexing new files: versioning assign several thousand versions to one of the files. The first time it happens, I look for mistakes in the NEF versioning definitions and I didn't find anything, so I delete the NEF file in Imatch and copy again into same folder. then I re scanned the file and no versions was found (That is correct, because this file had no versions).

Today I had the same behaviour scanning new files: as you can see in the attachment, one of the files has 7919 versions! I can't find any relation between the file and the wrong versions...

Any idea?

Best regards,

Carlos

Mario

Well, we need a bit more about this.

1. Provide your file relation setup (screen shots).
2. Provide file names added.
3. Provide the IMatch log file in Debug mode (Help > Support > ...) from a session where the problem happens.

Since this is a unique report (I don't recall any similar report ever), chances are that your file relations are wrong and pick up the wrong files.
Triple-check your file version rules, make sure that your regular expressions and folder limitations work as intended etc.
It will be very hard to replicate this on another system, if at all.

CMinguell

Many thanks for your quick reply,

The indexed file names are from CM20121202_50890.NEF to CM20121202_51024.NEF (134 files in a folder)

I don't have the log file for yesterday, so I have got one from today after a force update of the file with 7919 versions (CM20121202_50896.NEF), but the .txt file ha a size of 19189KB! So I can't attach it. I have uploaded it to DropBox:  https://www.dropbox.com/s/cvybppl9k1wi2yf/imatch_log20170426.txt?dl=0

I checked the version rules and used the "Expression Tester" with the NEF file name and some wrong version names, but the result is always "no match"

Best regards,

Carlos

Mario

For the NEF file in your first screen shot, please show us the contents of the version panel.
Is the TIFF file there listed as a version?

CMinguell

#4
Here it is!

The NEF file doesn't have a real TIFF version

Mario

This screen shot does not tell us much. Please right-click and let it show the details (file names).
As far as I understand your post, IMatch seems to identify .TIF files wrongly as versions of the NEF file? Or what is the problem?
Your version rule makes all TIFF files with similar names as the NEF file a version. Try to make it it more precise if it grabs the wrong files.

CMinguell

Sorry, here it is a new screenshot with details.

Yes, Imatch is identifying all the .TIF files contained in the target folder as versions of the file named CM20121202_50896.NEF, but only for this NEF file. The other NEF files (with very similar names) in the scanned folder are correctly assigned to their respective TIFF files versions in the target folder. See a second screen shot with the version panel of the file CM20121202_50900.NEF, which was correctly assigned.


Mario

I tried to repro that.
In a folder I added a NEF with the name

CM20121202_50896.NEF

and these other files:

CM20121202.tif
CM20121202_50896.tif
CM20121202_50896.jpg
CM20121202_50896-web.jpg

Using the default regular expressions (it seems you are using these too) only the

CM20121202_50896.tif and CM20121202_50896.jpg became versions. Which is correct.

CMinguell

Yes, this is how works for me most of the time... as I told in my first message, I have got this error just two times with two NEF files. Any idea about what is happening and what can I do to fix the problem?

Mario

No idea. We would need more details about the circumstances when this happens. This seems to be a unique problem for one user, one one machine, and with only certain files.