A single path with an invalid character prevents folder contents from being accessed

[GEPatSeeker]

I believe this is a bug. There are currently no means (outside of knowing the folder structure beforehand) to get the folder contents for a folder containing any keys with an invalid character in them.
This means if I have am accessing an S3 folder which I do not have control over I cannot access/list the files within it if the owner has created a single file named e.g. name=myFile.txt.

I can see a few ways of fixing this, but I know you don't accept contributions. My suggestions (which you are obviously free to ignore) are:

1. Use a different validator for paths built from response data to the validator used for paths built in general/in requests
2. Add some kind of override to allow for user to ignore specified 'invalid' characters (my preference as can then be applied to any path)

[lsymds]

Thanks for the report @GEPatSeeker

The problem with option 1 is that you would then be unable to act on those files/directories returned, and any existing code out there iterating and performing actions on those returned files/directories could find itself receiving unexpected exceptions. A potential solution to this is to skip returning them/erroring, but that doesn't sound ideal either (as it might confuse people as to why things aren't being returned).

The problem with option 2 is it removes the portability of the library. A valid path you create in one provider might not be valid in another, for example.

Short term, I will review the path validation rules. Neither Windows, Linux or S3 have a problem with the equals character being in the filename, so that should be an easy one to add.

Longer term, I'd like to do what you suggested in option 1 but return those directories and files under a Skipped property (with a reason) in the response.

If you need this done sooner rather than later, you could fork this repository, edit the validation code to suit your purposes, and compile a NuGet package from your forked version. The validation code is located under this path: src/Baseline.Filesystem/Internal/Validators/OriginalPathValidator.cs

[GEPatSeeker]

That is a good idea tbf, and I see you already have a ticket for adding more detail to the responses.

Re option 1, if the override was only in get requests you could safely return them as you should be able to assume that the overriding user will have added the appropriate handling. Any existing code would also not include the override, and by limiting it to get requests the user would still be prevented from using the library to create such files.

I do agree that skipping and returning those skipped is a cleaner solution though.

I've got a workaround for my issue as I can currently access the folders I need without accessing the folders containing the invalid chars. If they move them, I'll fork etc.
Cheers