Hacker News Reader

Comment by lelanthran | Hacker News Reader

> Most scripts just defend against the file existing

To me, any code calling a `DoesFileExist(filename)` type of function is a code smell.

There is no point to checking if the file exists. None. Ever![1]

There is never a case where this is useful. The only times I see code that checks for the existence of a file is when, on subsequent lines, the file is used as if it exists (no error-checking on open), which is a bug.

A line in code that checks for the existence of a file correlates, in my experience, very strongly with using that particular file in that specific buggy manner.

[1] You might say that it's to provide a better user experience, such as "Your config file does not exist, do you want to create it?" or similar, but that's still buggy if you're determining whether the file exists by checking existence.

View on HN

> 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.

> 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.

> 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/7f13af72f89452950226...

Okay..what is the alternative?

> Okay..what is the alternative?

Just ... open the file and handle the error?

What are you getting by checking that the file exists that you don't get from the 'file not found' error that the `openFile()` routine returns?

Because it doesn't matter if `doesFileExist()` returns true, you still have to handle the `file not found` error[1] when calling `openFile()` on the next line anyway.

[1] Just because the file exists when the program checked, that doesn't mean that the program can open it (permissions), that the file still exists (could have been removed between the call to check and the call to open), that the file is, in fact, a file that can be opened (and not a directory, for example), that the file is not exclusively locked (Windows) by some other process that opened it, etc. `doesFileExist()` tells you nothing that would change how the subsequent is written.

And if it's the initial configuration file?

> And if it's the initial configuration file?

You're still going to have to open it and handle the errors (in case it's the wrong permissions, or the filename is a directory, etc).

Checking if it exists doesn't make the subsequent code any easier or shorter - you still have to check for errors even if it exists.

That makes sense.

I guess we’re accustomed to thinking that absence of a file is not “exception-worthy” because it is expected under normal circumstances. But the cases you raised make sense.

Reply on news.ycombinator.com