Symbolic links and change detection

[Carlo Didier]

This may be useful for some other users, though I doubt that it will be many.

Recently, I noticed that iMatch did not automatically detect that images were changed. I had to manually re-scan them.

After some thinking and testing, I found out that the problem comes from a very special configuration I have on my PC:
The big part of my images are on a spinning 3TB HDD on a partition named P:.
For performance reasons, I recently moved the most recent images (i.e. folders for 2015 and 2016) to a partition on my 500GB SSD (partition F:).
As I wanted to keep a consistant folder structure with everything together on one drive, I created logical links (with mklink) so that the folders on F: appeared on P: alongside the folders for the older images (2014 and backwards).

This works perfectly. All my yearly folders are accessible under "P:\Photos Carlo", but the folders 2015 and 2016 are actually on the F: drive (the SSD).
Problem: When an image is changed (or added) on one of the folders on F:, iMatch does not automatically detect this anymore. If I relocate those folders in iMatch so that it sees them on F:, iMatch immediately (well, very quickly) sees that and rescans them to update its database.

I thought this might be usefule to one or two other users ...

[Mario]

In your configuration, Windows does not propagate the 'last modified' timestamp of your files. Hence IMatch, and probably other tools (backup etc.) will not see the files as changed.

Have you considered just mounting your other drive using the Windows drive manager? Maybe this works better, not tried this, mind.

[Carlo Didier]

In your configuration, Windows does not propagate the 'last modified' timestamp of your files. Hence IMatch, and probably other tools (backup etc.) will not see the files as changed.

The timestamp is changed, but Windows probably signals the change for a file on the F: drive and iMatch thinks the files are on P: ...

Have you considered just mounting your other drive using the Windows drive manager? Maybe this works better, not tried this, mind.

It already is another drive (F: instead of P: ). I don't understand what you mean. Anyway, what I wanted is that iMatch doesn't need to know that these folders are redirected to another drive.

[Mario]

When rescanning a folder, IMatch compares the last modified timestamp stored in the database with the last modified timestamp for the file as returned by Windows. It seems Windows does not propagate the correct time for these files, or otherwise IMatch would find that the timestamps differ. I don't know how IMatch deals with files. And when IMatch has indexed files from P: it will of course also not react on file system events for drives on drive F:

[Carlo Didier]

When rescanning a folder, IMatch compares the last modified timestamp stored in the database with the last modified timestamp for the file as returned by Windows. It seems Windows does not propagate the correct time for these files, or otherwise IMatch would find that the timestamps differ. I don't know how IMatch deals with files. And when IMatch has indexed files from P: it will of course also not react on file system events for drives on drive F:

On a rescan, iMatch sees the new timestamps and updates. The problem is the automatic detection that doesn't work because the drive letter doesn't correspond.
I can live with it, but it's good to know.

[Mario]

As I said, when Windows send "Folder X on drive P: has changed" and IMatch has no folder from drive P: it won't react. And should not! IMatch only monitors folders indexed by the database, not your entire system.