3 ms·

The same way it made it into production on POSIX? O_TRUNC is not default: https://man7.org/linux/man-pages/man2/openat.2.html https://man7.org/linux/man-pages/

The same way it made it into production on POSIX? O_TRUNC is not default: https://man7.org/linux/man-pages/man2/openat.2.html https://man7.org/linux/man-pages/man2/openat.2.html

sjm217 4y ago
I feel this is a bit different. At least O_TRUNC is an option that is shown in documentation right next to the open() function so the programmer has the opportunity to spot it. With the FileSavePicker, there is no such option available and they have to add a line to manually truncate the stream. Also, open() is a low-level call, whereas FileSavePicker is the supposedly easy-to-use high level feature. I would say it is closer to fopen(), which does truncate by default.
- eviks 4y ago
  These are very minor points. The main one is the same across platforms : bad defaults are common
chrismorgan 4y ago
Notwithstanding the lowest-level function open() working that way (and it’s honestly a somewhat different situation due to what it is and what the flags all are), fopen(), the more user-friendly interface with its mode strings, has "w" equivalent to including O_TRUNC in open() flags: https://man7.org/linux/man-pages/man3/fopen.3.html https://man7.org/linux/man-pages/man3/fopen.3.html
donmcronald 4y ago
I only have a very basic understanding of it, but skimming it makes me think that, in addition to leaving non-truncated files full of garbage around, that kind of open, overwrite, close pattern could be problematic on BTRFS. I wonder if that's one of the scenarios where BTRFS can end up with a bunch of extents that are full of mostly un-referenced blocks, but can't reclaim space because some of the blocks in the extent are (or BTRFS thinks they are) still in use.
- yencabulator 4y ago
  If you truncate, write new data, and close fd, nothing (in that file) refers to the old extents, and btrfs will garbage collect them just fine. The thing that hurts all copy-on-write systems is something like SQLite/Postgres/etc that mutates the file here and there; explicitly not overwriting it. chattr +C is the standard convention to opt out of copy-on-write, for those.

The same way it made it into production on POSIX? O_TRUNC is not default: https://man7.org/linux/man-pages/man2/openat.2.html https://man7.org/linux/man-pages/man2/openat.2.html

sjm217 4y ago

I feel this is a bit different. At least O_TRUNC is an option that is shown in documentation right next to the open() function so the programmer has the opportunity to spot it. With the FileSavePicker, there is no such option available and they have to add a line to manually truncate the stream. Also, open() is a low-level call, whereas FileSavePicker is the supposedly easy-to-use high level feature. I would say it is closer to fopen(), which does truncate by default.

eviks 4y ago
These are very minor points. The main one is the same across platforms : bad defaults are common

chrismorgan 4y ago

Notwithstanding the lowest-level function open() working that way (and it’s honestly a somewhat different situation due to what it is and what the flags all are), fopen(), the more user-friendly interface with its mode strings, has "w" equivalent to including O_TRUNC in open() flags: https://man7.org/linux/man-pages/man3/fopen.3.html https://man7.org/linux/man-pages/man3/fopen.3.html

donmcronald 4y ago

I only have a very basic understanding of it, but skimming it makes me think that, in addition to leaving non-truncated files full of garbage around, that kind of open, overwrite, close pattern could be problematic on BTRFS. I wonder if that's one of the scenarios where BTRFS can end up with a bunch of extents that are full of mostly un-referenced blocks, but can't reclaim space because some of the blocks in the extent are (or BTRFS thinks they are) still in use.

yencabulator 4y ago
If you truncate, write new data, and close fd, nothing (in that file) refers to the old extents, and btrfs will garbage collect them just fine. The thing that hurts all copy-on-write systems is something like SQLite/Postgres/etc that mutates the file here and there; explicitly not overwriting it. chattr +C is the standard convention to opt out of copy-on-write, for those.