well...in the meantime I found the (pretty obvious sorting) bug which caused the index issue with the test build.....and fixed it..
However I'm not really happy with the solution...
ok...it would rename hash/name collisions to "setname\filename" ...but it currently it does it to resolve the problem only...which means that it will only rename file with the found collision in one set...not the other....
Example:
Parent: A, B, C
Clone 1: D, E, F
Clone 2: D, G, H (where this D != D from the previous clone)
and this ends with:
Parent: A, B, C
Clone1: Clone1/D, E, F
Clone2: D, G, H
Currently I'm thinking if it would be better to also rename the second D:
Parent: A, B, C
Clone1: Clone1/D, E, F
Clone2: Clone2/D, G, H
...and what if the parent is part of the hash collision....should the parent keep the name while only the clones change?
Parent: A, B, C, D
Clone1: Clone1/D, E, F
Clone2: Clone2/D, G, H
or
Parent: A, B, C, Parent/D
Clone1: Clone1/D, E, F
Clone2: Clone2/D, G, H
.... waiting for ideas .....