* 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>
* Allow 0-byte reads at the end of a byte array
ReadBytes(ref offset, 0) threw ArgumentOutOfRangeException when offset
was equal to the array length, before the 0-byte case was handled. The
same happened for a 0-byte read from an empty array, and TryReadBytes
with a count of 0 at the end threw instead of returning true. The offset
check now accepts the end of the array for a 0-byte read only; reads past
the end still throw.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Handle 0-byte reads before the offset check
Same order as the stream version of ReadExactlyToBuffer, applied to
both byte array copies (Numerics.Extensions and IO.Extensions).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
This is being done to avoid any API-breaking changes in the future. If the values are set explicitly, added values either need to force a major version update or get added as the next-highest values.
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.
