Without understanding the way you are creating zip files in more detail, I can't say. I am imagining that you are copying the log files to a temp file, then zipping the copy. This copied file is not being modified during the zipping process,
if i understand correctly. you're telling me that "sometimes" the encryption doesn't happen. That sounds very odd, and ... impossible. But I'm sure there is something I don't understand about what you are doing.
As regards to whether the OS IO speeds can affect the behavior you describe - I don't see how that would cause the zip file to be created without a password. That makes no sense to me. I cannot envision a scenario where the IO speed causes encryption
to "vanish". So.... no.
There is a feature in DotNetZip where the app can completely SKIP the inclusion of a file if DotNetZip encounters an IO error while reading the input. Say, for example, your app creates a zip file and add 10 files into it. Then it calls
ZipFile.Save(). The library then reads each file in succession and writes to the output zip file. If there is an IO error reading one of the files, it's possible for DotNetZip to notify the application (via the ZipError event) and the application
can then advise DotNetZip to skip the file (or retry, or cancel the save entirely.... etc).
I can imagine a case where a VERY busy IO subsystem could cause a read to fail, and then DotNetZip would detect it, notify the app via the ZipError event, and then the app could advise "Skip". In this case that entry in the zip file would not be present
at all. It's not possible for the app to change or turn off the encryption on an entry, in this ZipError event.
Sounds like something else mysterious is going on in your case.