Hey community,

I'm a little bit drown in thoughts about the best/ fastest way to perform a lookup of the relation between two paths. My paths have an order (a number that determine the amount of sub-sequences/directories) and are already unified so there is no need take this into account. What I want to achieve is to determine if a given path is one of the following:

• The parents of the path tested; given A/B/C then is A the parent of B and C and A/B is the parent of C
• The same path as the path tested
• A totally different path as the path tested

I know there are some tricks in C# to speed string comparsion up, I'm currently using

public bool Contains(PathDescriptor subFolder)
{
    return subFolder.GetAbsolutePath().StartsWith(GetAbsolutePath(), StringComparison.OrdinalIgnoreCase);
}

but I was wondering if there is a better/faster solution to perform the same task. Again, I need to know if the path tested is any child directory regardless of the hirachy. This is important because for our tool we decided to allow local overrides for our Processor Units. This means the deeper the tool walks into the project directory, the more priority get the Processor Units found there.

Thanks in advance

It seems like you're discovering the file system (starting in directory X, retrieving all files and folders, and continuing recursively), store the paths, and afterwards try to do things with the path. Instead of only storing the path, you could as well/instead store the resulting priority, and use this value directly. (This of course assumes that the units are defined just by having files in the file system. If the settings contain arbitrary paths, then this wouldn't work, of course.)

Besides that, keep in Mind that path equality is case sensitive on some systems and case insensitive on others. Your current code would only work on Windows without problems, and could in theory cause issues on other systems.

29 minutes ago, Sacaldur said:

Mind that path equality is case sensitive on some systems and case insensitive on others

This however correct but we are working in a very small subset of the file system in our own SDK or the user's project directory. So if you create a tool that is called mytool and one the same spelling but in a different case in the same folder, than this is some kind of issue we don't address here

29 minutes ago, Sacaldur said:

It seems like you're discovering the file system

Not really, it is just a maximum of 3 levels of hirachy here. We start at the top level, so the SDK or project root and go down to the first level of sub-folders and collect all sub-folders in there. Then looking for the sub-foldes in there and collect all files found. The files won't process, only the paths because every Processor Unit attached to the global data pipeline has itself a directory where it was compiled from. Then the data is pushed to those units only, that are the standard units or located in certain directory in the SDK or project the data order is currently greater or equal.

For example I have the SDK path C:\\Users\...\SDK\ and the forge project inside the SDK located at C:\\Users\...\SDK\Tools\Forge, then a Processor Unit is compiled from the Forge directory, Data that is above the Forge directory will be passed to the default unit with an order of zero, data that is inside or below the Forge directory is passed to the unit defined there. So in this case, first the order is compared to early out anything don't matching at this point. After that the absolute path is matched against the remaining units because I can potentially have a diectory in my project folder that has the same order as the Forge directory.

Oh and I forgott to mention the priority between SDK folder and project folder. So local (project) units beat the global (SDK) ones but this is determined at startup

3 minutes ago, Shaarigan said:

This however correct but we are working in a very small subset of the file system in our own SDK or the user's project directory. So if you create a tool that is called mytool and one the same spelling but in a different case in the same folder, than this is some kind of issue we don't address here

Since you're comparing the entire path, it's not just folders inside your project that might only differ in capitalization. Take for example /home/Nom/... versus /home/nOm/... Even if you're currently only target Windows, you'll just assume your code to work once you don't look at it anymore.

4 minutes ago, Shaarigan said:

Not really, it is just a maximum of 3 levels of hirachy here. We start at the top level, so the SDK or project root and go down [...]

So you do a discovery of the file system, even if it's a limited one. As I wrote earlier, store the depth alongside the (relative) path and you don't have to guess it afterwards anymore. (At least I didn't see anything that prevents you from doing this.)

18 hours ago, Shaarigan said:

I'm a little bit drown in thoughts about the best/ fastest way to perform a lookup of the relation between two paths

I would likely use a list of sub-directory names for each path from the root, and then compare the names in both lists pairwise.