Can't remove irrelevant folders from database

[DavidOfMA]

Some time recently, for reasons I don't understand, IMatch started listing my main photo drive as a folder under the main drive icon. As a result, folders that I don't want to be in the database are listed, and if I remove them they come back the next time I start IMatch. I'd like to restore the database to its former style, where the "Photos" folder was listed under the main drive node, as other folders are for other drives I have. I've attached a screenshot of the folder structure to illustrate, but basically it's:

F:
--F:
----Backups
----Photos
...

instead of:

F:
--Backups
--Photos
...

I tried using Relocate to relocate F: to F:, which I suspect will fix the problem, but it ran for 4 hours and it wasn't clear anything was happening in that time. Is that the way to resolve this issue, or is there something else I can do?

The database diagnostics ran without error.

Thanks,
David

[beellecee]

+1

I also noticed this with the pre-2017 version. Not seen this happen yet with 2017.

[DavidOfMA]

The strange thing is that neither the C or D drives show this behavior. I'm going to let Relocate run for a longer period of time and see if it resolves it, and I'll report back here. Although after a while IMatch says it's "not responding" and appears to be hung, the working set changes from time to time, so it may actually be trying to relocate my files from Drive F to Drive F. I can't switch to 2017 yet because of the need to rewrite scripts I use all the time that will no longer work in the new scripting framework.

David

[J.D. McDowell]

I've had this for quite a long time now. My solution in the end was to create a partition and put nothing but my photo library on it. Not a proper fix, but it does work around the problem. iMatch will at some point scan the root of the partition, but I don't keep anything there so it's not an issue.

[DavidOfMA]

Has anyone submitted this as a bug report? If not, I'll do so once my Relocate completes. So far, 22 hours running!

[Mario]

Show log file. Perhaps you have created an infinite loop?
A relocate is a operation that takes a few seconds, max. IMatch just checks the file system to see if everything s there, then changes some objects in the database. Very fast.

[DavidOfMA]

Mario,

I'll check the log file. But the relocate issue is not really the problem.  The problem is the duplicated top-level drive and non-removable folders, as per the first post. Is there a fix for this?

[Mario]

If the root folder of F:\ is the problem, you can use the "Remove from Database" command. IMatch will ask you if you want to keep the sub-folders in the database, which is what you want.

I don't see a link between this and a relocation taking 12 hours...?

[DavidOfMA]

The relocate issue was an accidental finding. I wasn't sure what IMatch would do if I tried to remove the F: folder, so I tried using Relocate instead while waiting for the best solution from you, and found I'd apparently created an infinite loop. Strange, since this doesn't happen if I relocate a folder to itself, but ultimately irrelevant.

Anyway, glad to know how to fix this node problem. Thanks!

[Mario]

The Relocate should never get stuck infinite loop. If I could see the log file, maybe I could add some additional checks to prevent that.

As for the root folder of F: being added involuntarily, that is an issue that was reported a few times in the past. I have so far no clue why this can happen and I was unable to repro it. I suspect something with the file system monitoring, maybe file relations or something. Keep an eye on this please and when F:\ is added again, try to gather as much info as possible (what did you do before, your IMatch settings, file system layout etc.) This is one of the problems where only more input from users can help me figure it out.

[DavidOfMA]

Hi, Mario. The log file has been overwritten by subsequent uses of IMatch, but if the problem recurs, I'll also run Relocate on the top-level folder and recreate the apparent loop. I'm not sure it really is an infinite loop, though. The working set size changed over time, starting at around 450MB and dropping down to about 10MB after many hours of running, which makes me think something was changing, rather than that same cycle of instructions running over and over.

David