Checking if a file exists

[Army1987]

Is this a good way to check wheter a file already exists?

#include <stdio.h>
#include <stdlib.h>
int ask(const char *prompt);
typedef char filename[FILENAME_MAX];

int main(int argc, char *argv[])
{
FILE *in, *out;
filename in_name, out_name;
int overwrite = 0;
/* get filenames */
out = fopen(out_name, "r")
if (out != NULL) {
fclose(out);
printf("File %s already exists. ", out_name);
if (ask("Do you want to overwrite it?") == 1)
overwrite++;
else
exit(EXIT_FAILU RE);
}
/* etc... */
}

--
#include <stdio.h>
#include <stdlib.h>
int main(void) /* Don't try this at home */ {
const size_t dim = 256; int i;
for (i=0; malloc(dim); i++) /*nothing*/ ;
printf("You're done! %zu\n", i*dim);
puts("\n\n--Army1987"); return 0;
}

[Army1987]

"Barry Schwarz" <sc******@doezl .netha scritto nel messaggio
news:p3******** *************** *********@4ax.c om...

> name = overwrite ? tmpnam(NULL) : out;

I assume you meant out_name here.

Yes...

Isn't the test backwards?

No. The next statement opens out_name if overwrite is 0 (i.e. if a file
called that way didn't exist before), and creates a temporary file if a file
called out_name existed and the user answered yes when asked wheter to
overwrite it.

> if (overwrite) {
if (remove(in_name )) {

Didn't you mean out_name throughout this overwrite logic?

Yes... (Luckily enough I didn't test it...)

[Richard Bos]

Eric Sosman <es*****@acm-dot-org.invalidwrot e:

Keith Thompson wrote:

"Army1987" <pl********@for .itwrites:

Is this a good way to check wheter a file already exists?

[snip]

Testing whether a file exists often (not always, but often) means
you're asking the wrong question.

Why do you want to know whether the file exists? If it's so you can
decide whether to attempt some operation (e.g., reading from the file
if it does exist, or creating it if it doesn't), it's often better to
just go ahead and attempt the operation, and handle the error if it
fails. (This can be difficult in standard C if you're trying to
create a file; if I recall correctly, it's implementation-defined
whether attempting to create an existing file will clobber the file or
fail, but there are often system-specific ways to control this
behavior.)

I would prefer to see "File IRREPLACABLE.DA T exists.
Overwrite?" than to regret it at leisure ...

So would I, but there are circumstances where that is just not possible.

This is what you allude to in "system-specific ways," but
unfortunately Standard C's I/O is too diluted to do the job
unaided.

YM too portable. I don't think there _is_ a way to test for file
existence that would work everywhere <stdio.hdoes.

Richard

[=?utf-8?B?SGFyYWxkIHZhbiBExLNr?=]

Richard Bos wrote:

Eric Sosman <es*****@acm-dot-org.invalidwrot e:

This is what you allude to in "system-specific ways," but
unfortunately Standard C's I/O is too diluted to do the job
unaided.

YM too portable. I don't think there _is_ a way to test for file
existence that would work everywhere <stdio.hdoes.

If you mean exactly what you said, that doesn't seem relevant to me.
There's no way to open a file that works everywhere except for
<stdio.h>'s fopen, that's why fopen's there. Similarly, if there's no
way to test for a file's existence that works everywhere, that could
be why <stdio.hshoul d have provided a function for that.

If you mean that some systems supporting <stdio.hfunctio nality don't
provide any way at all to test whether a file exists, could you give
an example? It doesn't have to be a real world example, just a reason
of why a hypothetical implementation might not be able to provide it.
I can understand that media may be damaged, or directories may have
restricted access, so I can understand why a general fexist() that
returns true or false might be unimplementable , but in the specific
context, might any system not be able to reliably answer "if I try to
create file XXX, would I get an error, would I get a new file, or
would I overwrite an existing file"?

[=?utf-8?B?SGFyYWxkIHZhbiBExLNr?=]

Richard Bos wrote:

Eric Sosman <es*****@acm-dot-org.invalidwrot e:

This is what you allude to in "system-specific ways," but
unfortunately Standard C's I/O is too diluted to do the job
unaided.

YM too portable. I don't think there _is_ a way to test for file
existence that would work everywhere <stdio.hdoes.

If you mean exactly what you said, that doesn't seem relevant to me.
There's no way to open a file that works everywhere except for
<stdio.h>'s fopen, that's why fopen's there. Similarly, if there's no
way to test for a file's existence that works everywhere, that could
be why <stdio.hshoul d have provided a function for that.

If you mean that some systems supporting <stdio.hfunctio nality don't
provide any way at all to test whether a file exists, could you give
an example? It doesn't have to be a real world example, just a reason
of why a hypothetical implementation might not be able to provide it.
I can understand that media may be damaged, or directories may have
restricted access, so I can understand why a general fexist() that
returns true or false might be unimplementable , but in the specific
context, might any system not be able to reliably answer "if I try to
create file XXX, would I get an error, would I get a new file, or
would I overwrite an existing file"?

[Kenneth Brody]

Harald van D?k wrote:
[...]

If you mean that some systems supporting <stdio.hfunctio nality don't
provide any way at all to test whether a file exists, could you give
an example? It doesn't have to be a real world example, just a reason
of why a hypothetical implementation might not be able to provide it.

[...]

I seem to recall that someone posted several months back about a
"cryptograp hic filesystem", for which there was no way to test a
file's existence.

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer .h|
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:Th***** ********@gmail. com>

[Walter Roberson]

In article <46************ ***@spamcop.net >,
Kenneth Brody <ke******@spamc op.netwrote:

>I seem to recall that someone posted several months back about a
"cryptograph ic filesystem", for which there was no way to test a
file's existence.

Michael Wojcik initiated that subthread, discussing
'steganographic "deniable"' (SD) filesystems.

http://groups.google.ca/group/comp.l...cc67e712fe1a00
http://groups.google.ca/group/comp.l...634766e280d1bd
http://groups.google.ca/group/comp.l...f13f7c80b13640

--
Programming is what happens while you're busy making other plans.

[=?utf-8?B?SGFyYWxkIHZhbiBExLNr?=]

Walter Roberson wrote:

In article <46************ ***@spamcop.net >,
Kenneth Brody <ke******@spamc op.netwrote:

I seem to recall that someone posted several months back about a
"cryptograp hic filesystem", for which there was no way to test a
file's existence.

Michael Wojcik initiated that subthread, discussing
'steganographic "deniable"' (SD) filesystems.

http://groups.google.ca/group/comp.l...cc67e712fe1a00
http://groups.google.ca/group/comp.l...634766e280d1bd
http://groups.google.ca/group/comp.l...f13f7c80b13640

Thank you and Kenneth for the information. As I understand it from
these messages, on such a filesystem, reading foo.txt would always
succeed, regardless of whether it had ever been written to, and
writing to it would destroy any information stored in a file using any
other filename. Doesn't that mean a file's existence can reliably be
determined? It simply always exists.