Yes the current file IO "async" implementation isn't actually async.
It's different because `AsyncFile` keeps its `fd` field private. The Windows
one is using the version from `winlean` which actually wrapper for
`GetFileSize` from win32.
Also, windows has peculiarity of different handling whether the file handle is
synchronous and asynchronous one. That's why
I've never used async file I/O APIs, but my understanding is that they just
cover reading/writing the file itself. The size is metadata that comes from the
filesystem's catalog / inodes / whatever, not the file itself, and is very
cheap to get.
I suppose you _could_ get the file size
Not everyone uses async/await, and it's more common to use it for networking
than for files (in my experience.) The async file I/O is for code that does use
async and is worried enough about disk latency to want to avoid blocking on
disk I/O. That's more extreme than I've ever gone, but I've
OK, but in "async" version, there is nothing async at all (as I can understand).
So that asyncfile can use proc from io module for example.
Hi, working with async stuff decided to look at what async way of getting file
size and compare it to sync way.
Got no difference in principle, but there is 2 different implementations:
The "sync" version in io.nim:
proc getFileSize*(f: File): int64 {.tags: [ReadIOEffect],
