From: Glynn Clements <glynn.clements@virgin.net>
To: xmp <xmp@multipasto.net.co>
Cc: linux-c-programming@vger.kernel.org
Subject: Re: Misc C question
Date: Thu, 20 Jun 2002 14:23:41 +0100 [thread overview]
Message-ID: <15633.55133.760880.963357@cerise.nosuchdomain.co.uk> (raw)
In-Reply-To: <20020619214332.A299@nietzsche>
xmp wrote:
> hi, What is the correct unix-style way to check if a file exists ?
> create it ? and delete it ?.
There isn't a "correct" way.
1. You may not be able to tell whether or not the file exists, e.g.
because the process has neither read nor execute permission for one or
more of the directories in the file's path (or paths; due to hard
links, a file may have multiple pathnames).
2. Unless you're using the existence of the file as some sort of
"flag", checking for existence is seldom useful. More likely you want
to know if it's readable/writable/executable in a particular context
(the process' euid/fsuid, egid/fsgid and supplementary gids all affect
the result).
3. Functions which return information about the filesystem (e.g.
stat/lstat) return information about the past. Just because the file
existed (or did not exist) at the time of the check, there's no
guarantee that the file still exists (or doesn't exist).
> Maybe trying to fopen() it and if call != NULL it exist, else it
> doesnt?.
If the file doesn't exist, fopen() will return NULL, but there are
plenty of other reasons why fopen() may return NULL.
If you actually intend to read or write the file, the correct approach
is to attempt whatever you intend and to handle any failures. You
cannot predict in advance whether a given operation will succeed.
If you don't intend to read or write the file, then you shouldn't
attempt to open it, as that may have unintended consequences. For
files, directories etc it may update the last-accessed time; for
device files, the effects vary (e.g. open()ing /dev/st0 device may
rewind the tape).
--
Glynn Clements <glynn.clements@virgin.net>
next prev parent reply other threads:[~2002-06-20 13:23 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-06-20 2:46 Misc C question xmp
2002-06-20 3:10 ` mike
2002-06-20 4:44 ` xmp
2002-06-20 5:08 ` mike
2002-06-20 12:46 ` William N. Zanatta
2002-06-20 6:28 ` Oleg O. Ossovitskii
2002-06-20 8:05 ` Mohammed Khalid Ansari
2002-06-20 8:51 ` Re[2]: " Oleg O. Ossovitskii
2002-06-20 13:23 ` Glynn Clements [this message]
2002-06-20 20:42 ` GOMEZ NOGUERA DAVIDEDUARDO
2002-06-20 21:53 ` James Stevenson
2002-06-20 23:24 ` Glynn Clements
2002-06-20 23:24 ` Glynn Clements
2002-06-21 0:07 ` Christopher Quinn
2002-06-20 18:09 ` James Stevenson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=15633.55133.760880.963357@cerise.nosuchdomain.co.uk \
--to=glynn.clements@virgin.net \
--cc=linux-c-programming@vger.kernel.org \
--cc=xmp@multipasto.net.co \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).