(Un?)intended feature of List Directory Recursive

[GregSands]

I have just observed that the array of directory paths returned by List Directory Recursive is always every sub-directory of the root Path, no matter what pattern is used. My expectation (and what I'd wanted to use it for) had been that this output would contain only the sub-directories which matched the pattern, in the same way as the array of file paths is generated. Is this result the intended behavior, or a bug in the implementation?

[asbo]

I would agree that including any subdirectories which do not contain a matching file is a bug.

I think the bug itself is here:

The build array should be conditional iff the size of the "all files" array is > 0.

[GregSands]

I would agree that including any subdirectories which do not contain a matching file is a bug.

That's slightly different again - I was thinking it should contain all sub-directories whose names match the pattern, irrespective of any files in those directories. To me, that's the closest parallel to the core List Directory node.

[asbo]

Oooh, I read a little too much between the lines of what you said. Interesting; does the original node returns directories and files or just directories?

[GregSands]

Oooh, I read a little too much between the lines of what you said. Interesting; does the original node returns directories and files or just directories?

The built-in List Directory function returns all files and directories which match the provided pattern. My point is that List Directory Recursive recursively finds all files in all sub-directories which match the pattern, but it returns all sub-directories whether they match the pattern or not. I don't know whether this was intended, or whether it is a bug in the implementation. If it was intended it would be interesting to know why, and if not, I think it should be changed - though that would break any existing usage.

[Rolf Kalbermatter]

The built-in List Directory function returns all files and directories which match the provided pattern. My point is that List Directory Recursive recursively finds all files in all sub-directories which match the pattern, but it returns all sub-directories whether they match the pattern or not. I don't know whether this was intended, or whether it is a bug in the implementation. If it was intended it would be interesting to know why, and if not, I think it should be changed - though that would break any existing usage.

I think it is intended by precedence. In fact I'm totally surprised that List Directory does also filter directories based on the pattern. So what do you get if you want to list *.txt files? No directories at all? I had thought that in older versions of LabVIEW you got all the directories anyhow, but at least back to 7.0 the List Directory already filtered directories as well.

But looking at the List Directory Recursive I see that the Directory enumeration is done seperately without any pattern to indeed get around the "limitiation" of the LabVIEW native List Folder node, so it is clearly an intentional decision. I guess you could add an optional boolean that is set to false and in the true case just use the "directory names" output of the first Get Files by pattern function, skipping the "Get dirs" function. But changing the default is not really an option since it could and likely would break quite a few OpenG Tools such as the OpenG Package Builder, Commander and its decendent, the VIPM.

[GregSands]

I think it is intended by precedence. In fact I'm totally surprised that List Directory does also filter directories based on the pattern. So what do you get if you want to list *.txt files? No directories at all?

Yes, my expectation is that you'd get no directories at all (unless the directory name was Something.txt which is always possible, if unlikely). asbo's suggestion is 2nd most logical, that you'd get a list of the directories that contain files matching the pattern (though that can be gleaned from the file paths). But I can't see any logic in returning all directories.

But changing the default is not really an option since it could and likely would break quite a few OpenG Tools such as the OpenG Package Builder, Commander and its decendent, the VIPM.

I can see that now the utility is written, it's pretty difficult to change it, although it could always be deprecated with a new version written. Failing that, perhaps a boolean, or a 3-way enum - e.g. All (default), Files Match, Directories Match - could be added. Or I guess a polymorphic function is another way to extend/correct it.

[asbo]

I can see that now the utility is written, it's pretty difficult to change it, although it could always be deprecated with a new version written. Failing that, perhaps a boolean, or a 3-way enum - e.g. All (default), Files Match, Directories Match - could be added. Or I guess a polymorphic function is another way to extend/correct it.

I would be on-board with either of those options. I think it's weird and unexpected to get both directories and files matching my pattern; that said, I can't think a time when I wanted to pattern match directories, so there you have it.

Make the change and submit it for inclusion!