Automatic Add Child Folder

[Darius1968]

This is about my IMatch indicating a change - with a blue circle over "Alfred Hitchcock Presents" - has occurred to a top-level folder, but no actual update automatically happens in IMatch, without a manual rescan.  (See screenshot below, left) 



This, after a fresh launch of IMatch, with my DB.  Even after 5 min. of no activity, but the DB still loaded, the above screenshot (on the left) tells the story of subfolders - "Season 5", "Season 7" being the only two contained under "Alfred Hitchcock Presents", but a "Season 1" folder has been added outside of IMatch.  Again, it detects that some change has happened, but won't automatically rescan to add that folder, with its contents.  The above image (on the right) shows IMatch correctly representing my SSD folder structure, after a manual rescan of "Alfred Hitchcock Presents" has forced an update.  The attached log file is included for evaluation. 

[Mario]

Check your indexing settings: Indexing
Advanced monitoring or "include sub-folders" are the most important settings for this case.

[Carlo Didier]

On my PC this doesn't seem to work reliably either, with the correct options configured. Files and DB on local SSD.
Sometimes it works, sometimes not (more often not, actually).

[Mario]

Works here all the time.

Maybe an issue with the Windows notifications on your system, the virus checker, I don't know.
Just press Shift+F5 on the top-level parent to be sure.

[Carlo Didier]

It is perfectly reproducible here. Debug log attached.

While iMatch was not running, I copied two new folders to the folder tree which iMatch monitors:
"D:\Photos\Photos Carlo\2020\08\2020-08-27 - Spider" and "D:\Photos\Photos Carlo\2020\08\2020-08-27 - Spider\JPG"

Then I started iMatch. After a short delay, it picked up the first one and indexed it. But nothing happened with the JPG subfolder ... even after hours.
Database on drive F: and photos on drive D: are all internal SSDs.

I don't think this has to do with Windows notifications, as I copied the folders when iMatch wasn't running. Question is: When it detected the first new folder, why not its subfolder?

As another test, I removed the folders again from the DB. restarted iMatch and copied them back while it was running. This time, iMatch picked up both folders correctly.
So there seems to be a problem in the first scenario.

In your log file IMatch also reports that it has found an updated folder and is including sub-folder (2020-08-27 - Spider\JPG\), but no sub-folders are returned by the operating system...?

[Mario]

Which settings do you use for Edit > Preferences > Indexing?

[Carlo Didier]

see attached screenshot
looks like what I'd need IMHO

[Mario]

When I recall correctly, IMatch does not automatically add sub-folders to indexed folders, it only adds new files and updates existing files. Except when adv. folder monitoring is on (which may have other side-effects, please refer to the help for details). Which you have enabled. It also does not automatically remove files if you rename or move them in an external application. This behavior is for safety.

I've checked that. When I create some new folders in folders already in IMatch while IMatch is not running, the modified folder is detected when IMatch starts the next time and the new folders are added to the database. When I add new folders outside of IMatch while IMatch is running, the new folders are added to the database after a couple of seconds. I tried this on 2 PCs and a Windows tablet, it always worked. No problem reports from other users.

[Carlo Didier]

Well, it works for the topmost new folder, but not for the subfolders underneath that.
I can consistently reproduce this on two PCs.

[Mario]

Well, it works for the topmost new folder, but not for the subfolders underneath that.
I can consistently reproduce this on two PCs.

Please open a feature request and describe your requested changes.

As it is implemented now, advanced folder monitoring is off by default and limits recursion to one level. Only when you manually rescan a folder, all new sub-folders will be added recursively. This behavior is by design and unchanged, as far as I can tell from the version control, sine IMatch 5.

Adding any number of sub-folders and any number of levels automatically may cause some real problems.
For example, you index c:\images and c:\images\bla in your database.  This is not uncommon.
But c:\images has 200 other sub-folders you don't want in the database. Also not uncommon.
But if an application or Windows changes something in c:\images and IMatch would add all sub-folders of c:\images, recursively in adv. folder monitoring mode, users could end up in a world of pain. Not sure if this would be worth the trouble. As I said, this processing is basically untouched since IMatch 5 and it seems to work pretty well.

If you were misled by a page in the help where this is stated differently, let me know with the "Feedback" link at the bottom of that help page. I can then update the info.

[Carlo Didier]

For me it seems totally natural to add several levels of folders and of course I want them to be automatically indexed by iMatch.

The behavior isn't consistent either. I just now added a folder tree "09\2020-09-01 Landscapes and trees\JPG" with images in both "2020-09-01 Landscapes and trees" and "2020-09-01 Landscapes and trees\JPG", while iMatch was running. "09" didn't exist before.
iMatch detected the new folder "09" and added all images in all subfolders automatically ... which it shouldn't do by your reasoning. It should only add theose directly in "2020-09-01 Landscapes and trees".

So I removed them again from the database, closed iMatch, moved the folders to another place not indexed by iMatch. I started iMatch once to check and, of course they did not appear.
Then I closed iMatch again, moved the folders back and opened iMatch. It only detected the top level folder ...

Conclusion: if iMatch is running, it detects all levels of the folders, but if folders are added to the disk when iMatch is not running, only the top most new folder(s) are detected.
This is clearly an inconsistent behavior.

I think the explanation is that when iMatch is running it gets the events from Windows for each new folder, at all levels, and therefore detects and scans them. But when the folders are added when iMatch is closed, iMatch only detects the top most folder because the parent folder is marked as changed, but it won't scan the subfolders.
That would explain the different behviors, but it still is inconsistent and should be the same in both cases.

[Mario]

I have added this to my "check" list last week already.
No changes were done in this area for a long time so I don't recall the details anymore. Or why it works how it works.
I'll need to run some checks when I have a free slot.

[Mario]

This has been resolved. See release note #1245 for detailed information. https://www.photools.com/release-notes/.

[Carlo Didier]

This has been resolved. See release note #1245 for detailed information. https://www.photools.com/release-notes/.

Great! Thanks!
Also for #1236 

[Darius1968]

Good work!   

[Aubrey]

Should also be useful for me.
Looking forward to trying it.