Is the framework really abstract? Working with non-Windows file systems on Windows

[Joerki]

Hi guys, maybe this is a documentation issue, maybe more.

I'm currently (partially) inspecting the anchore/syft project that can be run on Windows and Linux. I recognized that the Windows implementation is broken. afero is used here, but since this module does not support path manipulating or informational functions (like Join, Base, Dir) they do all file path operations on their own, but with the "path" module instead of "path/filepath". Unfortunately they are not very communcative, so I place my questions and suggestions here.

I'm not a Go programmer yet, but coded a lot in many other programming languages.

My scenario is: I run an application on Windows, but my target file system may not be Windows (e.g. a tared file?).

According to your specification a programmer can interact with any filesystem, and the framework provides an abstraction layer for it. But this does not help if the programmer needs to manipulate or interpret paths, depending on the target file system path separator. The file separator of the target file system cannot be determined according to your documentation, so even a proper re-implementaion of path manipulation functions would not be possible.

In your documentation I see that you specify "FilePathSeparator" and comment that this is "os.Separator" . I could not find that one in the "os" documentation. My conclusion is that the PathSeparator is meant that is set for the operating system the application is running on, so Windows in my case "\", but this may not be valid for the file system I want to work with.

Another story are globs, definitions are (also with the Go standard library) OS depend, here the afero PathSeparator would need to specify the target file system's path separator, not the current OS one when I construct a glob dynamically for the target file system.

So finally, it would be very helpful for readers of your documentation to give advise about constraints they have in context of the operating system the programs are running on.

If you want to support target file systems that are not native to the current operating system, you should add support for path related functions to improve usability and prevent faulty implementations with it.

I like your project and approach very much (also if I would take it for software testing purposes). But my impression is that the framework cannot be used in an abstract way.

[Joerki]

Since I get no answer I close this one.