File window shows same pictures in two directories

[jwartenb]

I have a certain directory for every step in my workflow: geocaching, labeling, categorization, development.
At the end of the workflow all pictures are saved in a directory YYYY_MM.
After finishing one workflow step pictures of one photo session are moved with IMatch to the next directory.
Picture means in most cases the original RAW file with three buddies: JPG, XMP and DOP (DxO file).
I think since the 2019 version (but I am not sure) I see approx. 30 pictures in 2 directories.

Example:
Work on _ic001.nef is finished and files (RAW and buddies) have been moved to the "...\2018_12" directory on Drive G:
Picture is shown as version stack when I select this directory in the IMatch Media&Folders view.

But I also see this picture as version stack in the "...\01 Eingang" on drive M:
With  "right-click / Open in Windows Explorer" the Windows explorer opens the "...\2018_12" directory.
In the "...\01 Eingang" directory are no remaining buddies of the picture. The "...\2018_12" directory contains the expected buddies.

I have this problem with several directories. Every kind of rescan on both directories, Database Diagnostics and Compact and Optimize didn't solve the problem.

Any ideas how to solve the problem?

Thanks
Jochen

[Mario]

I must admit that I don't understand your workflow.

It would help if you post some screen shots of what you see. You can make screen shots by pressing <Alt>+<Print> on your keyboard. This copies the screen shot of the active window into the clipboard. Paste into an image editor application, crop to show only the relevant part and save as JPEG. Attach the screen shot to your post.
Seeing things makes complex workflows or problems easier to understand.

IMatch cannot show the same image in two different folders. IMatch can show the same file in any number of categories.
I have never heard about a similar issue as far as I recall.

1. Run a database diagnosis to ensure your database is OK.
2. Put this variable expression into the VarToy app:

{File.FullName}
{File.OID|cast:int}
3. Select the first file and copy the results from the VarToy somewhere (Windows Notepad, for example).
4. Go to the other folder where you see the 'wrong' copy of the file.
5. Again copy the VarToy contents to Notepad.

If things are working correctly, both files should show different folders in VarToy, and different OIDs (which is the unique internal number).

Since this is related to stacks, maybe delete and re-create the stack.

[jwartenb]

Attached screenshots of the "correct" path and the "wrong" path (file _DS78926.NEF).
Furthermore the result of a disk search: only one version of the file on the disk.

Output of VarToy:
Original - M:\Work\2018_08_Work\:
M:\Work\2018_08_Work\_DS78926.NEF
99620

Wrong file - M:\Neuzugänge\01 Eingang\:
M:\Work\2018_08_Work\_DS78926.NEF
99620

Thanks
Jochen

[Mario]

The file exists only once in the database, in the folder shown in the VarToy app => M:\Work...

I have no idea why the same file is shown in another folder. I don't recall a similar support case ever.

Did you run a database diagnosis as I asked for above?
What does it report?

Did you use the Relocate command in the past? Maybe something went wrong there...?
Does your Linux box use some sort of drive/folder virtualization or anything?

[jwartenb]

I rund the database diagnostics program several times. Always without any errors.

The relocate command was definitly not used for these files.

In my workflow I often move a lager amount of files from one directory to another (e.g. 100 files shot on one day). Sometimes I get an error like "file in use". On the next try the file will be moved.

To avoid from misunderstandings: my PC is a Windows 64bit PC. Cygwin is a POSIX-compatible environment that runs natively on Microsoft Windows. I prefer to use UNIX shell instead of DOS shell, because I worked with UNIX before using Windows / DOS.

Drives affected with the probem are regular windows NTFS partitions.

Thanks
Jochen

[Mario]

If not even the diagnosis finds something unusual, this is a truly obscure case. I would need your database here in lab to analyze this further. Never had a similar case and if the same file would be in more than one folder, the diagnosis should find this error. Although, it only runs the tests I've implemented and I'm not sure if I've added a test to check for multiple folder links t the same file...

[jwartenb]

My *.impag file has a size of approx. 0,9 GB.

I would give you copy. How can we handle it?

Thanks
Jochen

[Mario]

You can upload it to your cloud space (Dropbox, OneDrive, Google Drive ...) and send me a link. I will download it and let you know what I find out. Then I will delete the database from my system.

[thrinn]

I wonder...
Your screenshots look a bit different to my media & folder view:
According to the path shown in the file windows header, your "Work" folder is at the top level of drive M:, right? But the folder tree shows it at the second level, with an unnamed folder at the top level. It also shows that a rescan is needed.
Honestly, I have no idea if these observations help...

[Mario]

Thanks for sending the database. There were really some files linked to the wrong folder.
I have no idea how this can happen. The only situation I could come up with was

a) IMatch is moving files between folders.
b) After adding the files to the target folder, IMatch crashes or there is a power failure
c) The database system, for unknown reasons, fails to undo the incomplete transaction when the database is loaded the next time (which would normally undo the half-done change).
d) c) Could happen if the database is restored from backup after the power failure but the transaction logs are not.

Anyway, I have found out that there actually was a diagnosis step which checked this. And found it. And wrote 'Warning' entries to the log file!
But it did not increase the warning counter so, in the dialog and in the stats at the end of the log file, these warnings were not reported.
In addition, while trying to fix the problem, the diagnosis did update the file, but not the 'wrong' folder under all conditions.

I have fixed both issues now and in the rare case that another user will have a database with the same problem, the diagnosis can repair it. Maybe we learn about the reason for such an obscure problem if another user can remember when it happened.

For your convenience, I have uploaded a repaired version of the database to one of my servers. See your inbox for download link and details.