* Do not follow linked directories in SafeGetFiles outside of Windows
SafeGetFiles with SearchOption.AllDirectories follows directory symlinks.
On Linux, the UDF view of some PC/Mac hybrid discs has symlinks whose
target reads as empty, and each one resolves to its own folder, so the
recursion never ends (fixes#2, SabreTools/BinaryObjectScanner#276).
Outside of Windows, walk the tree one directory at a time and do not enter
directories that carry FileAttributes.ReparsePoint. Files are matched with
Directory.GetFiles per directory, so the pattern behaves as before, and the
order is the same breadth-first order. Windows keeps Directory.GetFiles.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Do not follow linked directories in the other AllDirectories overloads
SafeGetDirectories and the SafeEnumerateDirectories, SafeEnumerateFiles
and SafeEnumerateFileSystemEntries wrappers follow directory symlinks in
the same way. On Linux, with one directory linked to itself,
SafeEnumerateFiles returns 43 files instead of 2, and with three such
links it is still running after 10 seconds.
The walk from SafeGetFiles is now a lazy iterator that all of them share,
so the Enumerate wrappers stay lazy. Each directory is listed with the
matching overload without SearchOption (Directory.GetFiles,
SafeEnumerateFiles and so on), so patterns and inaccessible directories
behave as in the recursive search. If the attributes of a subdirectory
cannot be read, such as below a directory without execute permission, it
is entered anyway, so it fails in the same way as in the recursive search.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Check for linked directories without catching exceptions
DirectoryInfo.Exists returns false where the attributes cannot be read, and the criteria for the walk are checked one at a time with their reasons.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Even though there are relatively few collections extensions right now, there is a relatively high chance that other extension will be used in the future.
This change looks dramatic, but it's just separating out the already-split namespaces into separate top-level folders. In theory, every single one could be built into their own Nuget package. `SabreTools.IO.Meta` builds the normal Nuget package that is used by all other projects and includes all namespaces. `SabreTools.IO` builds to `SabreTools.IO.Common` to avoid overwriting issues on publish.
