when rescanning a share, the number of errors regarding “recursion” changes. After first scan: 141 entries. Second scan: 225 entries. Third scan 397 entries… the number of files/folders shown by st increases…
the scan process seems to stop somewhen…
** I counted one share (drive G:) with “dir /s” -> 34771 files, 5349 folders (a lot of Apple Mac files, a reason for the high number of folders?)
** using windows explorer -> mark all entries on mapped drive > properties > 37372 files, 1783 folders (ugh?)
** ST scan reports 4944 files, 566 folders (even after rescan), this will be hard work to examine the logfile.
Assuming that there is in fact no recursion, this is triggered by some sort of funkiness in reported file IDs. Maybe they are random and change over time, causing conflicts. Whether that’s on the “i” file server, or Windows side, or a combo, I doubt that there is something relevant revealed by figuring out precisely which items are caught in the net. I’m not sure how to debug this, really. Maybe log a support ticket with IBM.
Also it worked with st on earlier versions - problems came with update to 1.10
Will need to do more investigation and talk to IBM devs but i think this should not be the problem. Bigger question is - how to find out what exactly does trigger the recursive error.
So 1.9.0 doesn’t have this issue? That’s odd, I don’t think anything relevant was changed there. The ancestor checks were added in 1.7.0, iirc.
The check is that the scanner keeps a stack of parent directories, and compares each new directory found to them using os.SameFile. If that returns true it aborts with infinite recursion detected.
The fact that rescanning multiple times yields different results sounds to me like file IDs are generated on the fly and reused, leading to this issue. The file IDs you show seem “suspiciously” low and sequential to me as well, which doesn’t prove anything but doesn’t rule out the above. I don’t think a file ID on a normal Windows file changes. Maybe it does, on these things.
What exactly is it you want to know? There is a list of affected files/dirs in the UI (the failed items list) and the conflict is always with a parent dir.