3 ms·

> There is no point to checking if the file exists. None. Ever![1] > There is never a case where this is useful. Only a Sith deals in absolutes. What about t

by mlyle 3y ago

> There is no point to checking if the file exists. None. Ever![1] > There is never a case where this is useful. Only a Sith deals in absolutes. What about the use case when you change behavior when a sentinel file exists and don't care about the contents? ;) e.g. touch firstrun It can also be useful if there's a whole bunch of prerequisites you're going to check before doing a bunch of work; yes, opening the descriptor and keeping it around might be nicer, but... Also, what about if you want to not overwrite existing output if it exists? O_CREAT|O_EXCL could be better (and important to use if the overwrite check has security implications)... though that doesn't exist in fopen(3) and you'd need to use fdopen which is inconvenient and risky in its own ways.

lelanthran 3y ago
> Only a Sith deals in absolutes. Point taken :-) > What about the use case when you change behavior when a sentinel file exists and don't care about the contents? You'll still care that you can write that file, right? > It can also be useful if there's a whole bunch of prerequisites you're going to check before doing a bunch of work; yes, opening the descriptor and keeping it around might be nicer, but... But, after you've checked the prerequisites, and you start your main work, you're still going to have to handle the case in that main work that one of the files you checked has the wrong permissions/is locked/was deleted. It's not unusual for users to accidentally open a program twice by misclicking it when they only opened it once. > It can also be useful if there's a whole bunch of prerequisites you're going to check before doing a bunch of work; yes, opening the descriptor and keeping it around might be nicer, but... You answered this question below for the `open`/`openat` syscall. For `fopen` ... > though that doesn't exist in fopen(3) It has been in the standard since C11, I believe - mode `"x"` for exclusive create and open. You can use it with most C implementations today as most systems support C11.
- NekkoDroid 3y ago
  > You'll still care that you can write that file, right? Sometimes you don't need it. systemd itself just checks that `/etc/initrd-release` exists and runs in initrd mode changing its default target to boot into (IIRC you can also manually change the default target to `initrd.target` in the initrd, but this way the default systemd vendored files don't need to be touched). https://github.com/systemd/systemd/blob/7f13af72f894529502267e7eed8e8b480a350345/src/basic/initrd-util.c#L31 https://github.com/systemd/systemd/blob/7f13af72f89452950226...

by mlyle 3y ago

lelanthran 3y ago

> Only a Sith deals in absolutes. Point taken :-) > What about the use case when you change behavior when a sentinel file exists and don't care about the contents? You'll still care that you can write that file, right? > It can also be useful if there's a whole bunch of prerequisites you're going to check before doing a bunch of work; yes, opening the descriptor and keeping it around might be nicer, but... But, after you've checked the prerequisites, and you start your main work, you're still going to have to handle the case in that main work that one of the files you checked has the wrong permissions/is locked/was deleted. It's not unusual for users to accidentally open a program twice by misclicking it when they only opened it once. > It can also be useful if there's a whole bunch of prerequisites you're going to check before doing a bunch of work; yes, opening the descriptor and keeping it around might be nicer, but... You answered this question below for the `open`/`openat` syscall. For `fopen` ... > though that doesn't exist in fopen(3) It has been in the standard since C11, I believe - mode `"x"` for exclusive create and open. You can use it with most C implementations today as most systems support C11.

NekkoDroid 3y ago
> You'll still care that you can write that file, right? Sometimes you don't need it. systemd itself just checks that `/etc/initrd-release` exists and runs in initrd mode changing its default target to boot into (IIRC you can also manually change the default target to `initrd.target` in the initrd, but this way the default systemd vendored files don't need to be touched). https://github.com/systemd/systemd/blob/7f13af72f894529502267e7eed8e8b480a350345/src/basic/initrd-util.c#L31 https://github.com/systemd/systemd/blob/7f13af72f89452950226...