Chungalin

I'm aware of the restrictions of using unbuffered file operation. To me, the "dirtiest" part is when reading or writing the end of the file and its size is not an exact multiple of the page size. But that's a boundary condition and it can be worked around reopening the file in normal mode. For regular operation it should not be difficult to implement a small intermediate buffer (64-128KB would be enough) and new Read / Write functions that encapsulate the lower level alignment and "granularity". Just my humble thoughts to improve an already excellent app. Thanks for your attention.

I think that you should consider to add an option to enable UNBUFFERED I/O to certain operations. For instance, Verify. It's useless to use regular cached I/O to verify a burn against an image on HDD. Even if you have a lot of RAM, after a 4.3GB Verify operation the system cache has been flushed just to store some data that won't be accessed again, and the system gets very slow during and after an operation like that. Also, many CD/DVD image operations are sequential and thus they don't benefit from disc caching, but they can trash the previous cache status of the system. Please consider the UNBUFFERED flags in CreateFile Win32 API. Many other large files dealing apps already use this efficient feature.