What's the new version of IArchiveFile.CopyTo?

[focustense]

I used to have some very simple code:

var file = folder.Files
    .SingleOrDefault(f => string.Equals(f.Path, archiveFilePath, StringComparison.OrdinalIgnoreCase));
if (file == null)
    throw new Exception($"Couldn't find file {archiveFilePath} in archive {archivePath}");
using var fs = File.Create(outFilePath);
file.CopyDataTo(fs);

Looks like CopyDataTo has been removed in the current version, and presumably replaced by AsStream. But I can't get AsStream to work. With the following code:

    using var fs = File.Create(outFilePath);
    using var afs = file.AsStream();
    afs.CopyTo(fs);

I get this error:

System.ArgumentOutOfRangeException: Specified argument was out of the range of valid values. (Parameter 'Tried to write more data than was available: 32768 > 29188')  
  at Noggog.Streams.FramedStream.Read(Byte[] buffer, Int32 offset, Int32 count) in D:\a\CSharpExt\CSharpExt\Noggog.CSharpExt\Streams\FramedStream.cs:line 52  
  at System.IO.Stream.CopyTo(Stream destination, Int32 bufferSize)

I also get the same error by specifying an explicit size:

    afs.CopyTo(fs, (int)file.Size);

I set a breakpoint and can see that both file.Size and the actual FramedStream length are both 29188, so I'm not actually asking it to write any more than what's available. I can't figure out where the value 32768 is coming from. Am I running into some confusion over compressed vs. uncompressed size, or is the FramedStream implementation just bugged?

Also, I realize I can work around this by doing fs.Write(file.GetSpan()) (or GetBytes) for now, but it's going to be slower with the extra memory round trip.

[Noggog]

The new version of CopyTo() is the code you mentioned in the second snippet.

ArchiveFile.CopyTo was just a port-over copied from WJ's implementation. The reason it was swapped out for AsStream is that CopyTo is just one call of many found on Stream. If we wanted expose the full set of Stream-style API, there would be a lot more calls to implement. It's much just easier to expose as a Stream outright, and let users interact with the fully featured object how they want from there.

As far as why there's an error, might just be a bug in FramedStream's implementation. I'm guessing you're on the newest v0.30.4?
I'll be looking around the code to see if I can spot why it would be acting the way you're experiencing, but if you can point me to a specific BSA/subfile I can probably get to the bottom of it ASAP.

BTW, congrats on the app/release! Looking super cool!

[focustense]

Yes, just upgraded to 0.30.4. I am reasonably sure that this error will be repro in any compressed BSA, since I always see it on the first file I try to extract, and the app's concurrency means it won't always start with the same file.

Did the old version have to allocate memory for the entire file? Maybe it's just my imagination, but it seemed to run a lot slower using GetSpan.

(I'm not sure if I'd say the app is "released" just yet, but thanks!)