3 ms·

It's notable that in practically every other programming language on every platform the default is to truncate the file to 0 bytes when opened in write (not app

It's notable that in practically every other programming language on every platform the default is to truncate the file to 0 bytes when opened in write (not append) mode. This isn't one of those things where there are two schools of thought where people take sides. It's a completely baffling decision to buck all convention vs. common sense.

Someone 4y ago
> It's notable that in practically every other programming language on every platform the default is to truncate the file to 0 bytes when opened in write (not append) mode Examples of ‘Open’ calls that require setting a bit in the ‘flags’ argument to truncate an existing file: - https://learn.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-openfile https://learn.microsoft.com/en-us/windows/win32/api/winbase/... - https://man.freebsd.org/cgi/man.cgi?query=open&sektion=2&n=1 https://man.freebsd.org/cgi/man.cgi?query=open&sektion=2&n=1
- okanat 4y ago
  You're comparing system call interfaces to higher level standard API defaults. Not really an apples to apples comparison. System calls are special low-level interfaces. The requirement for reading their docs carefully and general care is expected at that level. A higher level API shouldn't contain gotchas like this.
- moefh 4y ago
  Wow, that Win32 OpenFile function is truly cursed: - If you don't specify a directory, Windows will look for the file in a bunch of directories, but the current directory is not the first place searched. - The lpReOpenBuff is annotated as [out], but is an input when uStyle contains the OF_REOPEN flag. - The function is named OpenFile, but can be used to delete a file. Even better, the documentation is not clear what to do with the return value on success: is it a valid file handle that must be passed to CloseHandle, or just a dummy non-error file handle? - You can also use it to check the existence of the file -- the documentation says it will open and then close the file. What's the return value in that case? Is it a stale file handle, a dummy, or do you still have to close it?
  - Someone 4y ago
    You’re forgetting this one: you can specify a flag that makes the call display a dialog box if a requested file does not exist. Yes, this call to open a file can run an event loop that lets the user create directories, rename files, possibly even format floppy disks, etc. If you want a prime example of a layer violation, this is it. Its replacement “CreateFile” (https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-createfilea https://learn.microsoft.com/en-us/windows/win32/api/fileapi/...) is a lot saner, but still has this: “If you rename or delete a file and then restore it shortly afterward, the system searches the cache for file information to restore. Cached information includes its short/long name pair and creation time.” That’s intended to make it easier for “Save” operations in document-based applications to keep the short name of the file, creation time and file flags around.

Someone 4y ago

> It's notable that in practically every other programming language on every platform the default is to truncate the file to 0 bytes when opened in write (not append) mode Examples of ‘Open’ calls that require setting a bit in the ‘flags’ argument to truncate an existing file: - https://learn.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-openfile https://learn.microsoft.com/en-us/windows/win32/api/winbase/... - https://man.freebsd.org/cgi/man.cgi?query=open&sektion=2&n=1 https://man.freebsd.org/cgi/man.cgi?query=open&sektion=2&n=1

okanat 4y ago
You're comparing system call interfaces to higher level standard API defaults. Not really an apples to apples comparison. System calls are special low-level interfaces. The requirement for reading their docs carefully and general care is expected at that level. A higher level API shouldn't contain gotchas like this.
moefh 4y ago
Wow, that Win32 OpenFile function is truly cursed: - If you don't specify a directory, Windows will look for the file in a bunch of directories, but the current directory is not the first place searched. - The lpReOpenBuff is annotated as [out], but is an input when uStyle contains the OF_REOPEN flag. - The function is named OpenFile, but can be used to delete a file. Even better, the documentation is not clear what to do with the return value on success: is it a valid file handle that must be passed to CloseHandle, or just a dummy non-error file handle? - You can also use it to check the existence of the file -- the documentation says it will open and then close the file. What's the return value in that case? Is it a stale file handle, a dummy, or do you still have to close it?
- Someone 4y ago
  You’re forgetting this one: you can specify a flag that makes the call display a dialog box if a requested file does not exist. Yes, this call to open a file can run an event loop that lets the user create directories, rename files, possibly even format floppy disks, etc. If you want a prime example of a layer violation, this is it. Its replacement “CreateFile” (https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-createfilea https://learn.microsoft.com/en-us/windows/win32/api/fileapi/...) is a lot saner, but still has this: “If you rename or delete a file and then restore it shortly afterward, the system searches the cache for file information to restore. Cached information includes its short/long name pair and creation time.” That’s intended to make it easier for “Save” operations in document-based applications to keep the short name of the file, creation time and file flags around.