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_FAILURE);
}
/* 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;
}
26  4906 
Army1987 said:
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_FAILURE);
}
/* etc... */
}
It's about as good as you're going to get under ISO C, but it's not
reliable. The open might fail for other reasons than the non-existence
of the file (e.g. disk error, no read permission, etc). And there is no
guarantee that the file will continue to exist after the fclose, or
that it will continue not to exist (if indeed it did not exist) after
the fopen failure.
Abstract this functionality into your "non-portable stuff" module, and
consult your implementation's documentation for details of how to solve
this problem (if indeed there is a solution) on the platform that it
targets.
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk
email: rjh at the above domain, - www.
Army1987 <pl********@for.itwrote:
Is this a good way to check wheter a file already exists?
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++;
No, that's not a good idea. There could be lots of other reasons
why the fopen() failed, starting from missing permission to open
it for reading up to e.g. having run out of file descriptors. So
you shouldn't blindly assume that the file does not already exist
just because fopen() in read mode failed (and, by the way, it is
also possible on a multitasking system that the file gets created
by another process between the time you did the test and the time
you open the it). If you want to avoid overwriting data in the
file if it already exists fopen it in append mode and check if
with ftell() if you're at the very start of the file (but that
still will not allow to distinguish the cases of the file not
existing at all and the file existing but being empty).
Regards, Jens
--
\ Jens Thoms Toerring ___ jt@toerring.de
\__________________________ http://toerring.de
At about the time of 4/7/2007 6:51 AM, Army1987 stated the following:
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_FAILURE);
}
/* etc... */
}
I think that Microsoft implements a file exists call. On Unix systems,
you can stat(2) the file and check if errno = ENOENT. Granted, this is
not portable, but it works.
--
Daniel Rudy
Email address has been base64 encoded to reduce spam
Decode email address using b64decode or uudecode -m
Why geeks like computers: look chat date touch grep make unzip
strip view finger mount fcsk more fcsk yes spray umount sleep
"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.)
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
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.DAT exists.
Overwrite?" than to regret it at leisure ...
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.
--
Eric Sosman es*****@acm-dot-org.invalid
"Richard Heathfield" <rj*@see.sig.invalidha scritto nel messaggio
news:tM******************************@bt.com...
Army1987 said:
>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_FAILURE);
}
/* etc... */
}
And there is no
guarantee that the file will continue to exist after the fclose.
That's the problem. If the file couldn't be opened for some other reason
other than not existing, I would expect the fopen(out_name, "w") later in
the program to fail (unless the user has permission -w- on the file, in
which case I think he (or its owner) *deserves* to lose it, or some other
problem which I can't imagine).
Now if it is possible that out = fopen(out_name, "r"); fclose(out); deletes
the file, I'd better find another way...
"Keith Thompson" <ks***@mib.orgha scritto nel messaggio
news:ln************@nuthaus.mib.org...
"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.
7.19.5.3.3 says that fopen(name, "w") "truncate[s] to zero length or
create[s] text file for writing".
Simply opening the file for writing loses its contents if it already exists.
Army1987 said:
<snip>
Now if it is possible that out = fopen(out_name, "r"); fclose(out);
deletes the file, I'd better find another way...
Well, I wouldn't expect that to happen! But I would not be surprised by
the following sequence of events:
1) you open the file read-only
2) you close the file
3) another process deletes the file
4) you act on your belief that the file exists
Multi-user / multi-process systems can be tricky, can't they?
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk
email: rjh at the above domain, - www.
Army1987 <pl********@for.itwrote:
"Keith Thompson" <ks***@mib.orgha scritto nel messaggio
news:ln************@nuthaus.mib.org...
"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.
7.19.5.3.3 says that fopen(name, "w") "truncate[s] to zero length or
create[s] text file for writing".
Simply opening the file for writing loses its contents if it already exists.
In order to avoid just that there's the "a" or "a+" mode you can
pass to fopen() instead of "w" to open it in append mode. Then an
already existing file won't get truncated and you're positioned
at the end of the file while, if the file doesn't exist, it be-
haves as if you had used "w".
Regards, Jens
--
\ Jens Thoms Toerring ___ jt@toerring.de
\__________________________ http://toerring.de
"Richard Heathfield" <rj*@see.sig.invalidha scritto nel messaggio
news:E4******************************@bt.com...
Army1987 said:
<snip>
>Now if it is possible that out = fopen(out_name, "r"); fclose(out);
deletes the file, I'd better find another way...
Well, I wouldn't expect that to happen! But I would not be surprised by
the following sequence of events:
1) you open the file read-only
2) you close the file
3) another process deletes the file
4) you act on your belief that the file exists
Multi-user / multi-process systems can be tricky, can't they?
Probably, in this very case it wouldn't harm so much, because I meant to do
something like:
#include <stdio.h>
#include <stdlib.h>
int ask(const char *prompt);
typedef char filename[FILENAME_MAX];
int main(int argc, char *argv[])
{
char *name;
FILE *in, *out;
filename in_name, out_name;
int overwrite = 0;
/* get filenames */
in = fopen(in_name, "r");
if (in == NULL) {
perror("Unable to read from file");
exit(EXIT_FAILURE);
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_FAILURE);
}
name = overwrite ? tmpnam(NULL) : out;
out = fopen(name, "w");
if (out == NULL) {
fclose(in);
perror(overwrite ? "Unable to create temporary file"
: "Unable to create destination file");
exit(EXIT_FAILURE);
}
/* do stuff */
fclose(in);
if (fclose(out)) {
perror(overwrite ? "Unable to close temporary file"
: "Unable to close destination file");
exit(EXIT_FAILURE);
}
if (overwrite) {
if (remove(in_name)) {
perror("Unable to overwrite destination file");
fprintf("The temporary file is available as %s", name);
exit(EXIT_FAILURE);
}
if (rename(name, in_name)) {
perror("Unable to rename temporary file");
fprintf("The temporary file is available as %s", name);
exit(EXIT_FAILURE);
}
}
return EXIT_SUCCESS; /* Finally... */
}
(The actual error messages are just examples, I would use fprintf so to
include filenames.)
The very worst thing that could happen is that the destination filename
would have a wrong, temporary name, which the user would know so to rename
it by hand... or is it?
"Army1987" <pl********@for.itha scritto nel messaggio
news:ev**********@tdi.cu.mi.it...
fprintf("The temporary file is available as %s", name);
Sorry. I meant:
fprintf(stderr, ...);
"Army1987" <pl********@for.itwrites:
"Keith Thompson" <ks***@mib.orgha scritto nel messaggio
news:ln************@nuthaus.mib.org...
>"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.
7.19.5.3.3 says that fopen(name, "w") "truncate[s] to zero length or
create[s] text file for writing".
Simply opening the file for writing loses its contents if it already exists.
Thus "often" rather than "always". See also Jens's followup about "a"
(append) mode.
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
>"Richard Heathfield" <rj*@see.sig.invalidha scritto nel messaggio
>news:E4******************************@bt.com...
>... I would not be surprised by the following sequence of events:
1) you open the file read-only
2) you close the file
3) another process deletes the file
4) you act on your belief that the file exists
Multi-user / multi-process systems can be tricky, can't they?
In article <ev**********@tdi.cu.mi.it>, Army1987 <pl********@for.itwrote:
>Probably, in this very case it wouldn't harm so much ... [code snipped]
>The very worst thing that could happen is that the destination filename
would have a wrong, temporary name, which the user would know so to rename
it by hand... or is it?
There is definitely something worse that could happen. Richard
Heathfield's example covers a case like:
fp = fopen(name, "r");
if (fp != NULL) {
fclose(fp);
/* allow time to pass */
fp = fopen(name, "r");
/* assumption here: fp != NULL */
}
Your code (which I snipped), however, has a case more like this:
fp = fopen(name, "r");
if (fp != NULL) {
fclose(fp);
/* allow time to pass */
...
} else {
--- fp = fopen(name, "w");
...
}
Now, at the line I marked with an arrow "--->", you assume that
since fopen-for-reading returned NULL, the file does not exist (or,
as you noted elsewhere, that it has bizarre permissions, in which
case the user is shooting himself in the foot and there may not be
much we can do about it anyway).
The more serious problem -- and one which occurs in real-world
security holes on these multi-user, multi-process systems that
Richard Heathfield mentioned -- occurs when enough time passes
between the first fopen (with "r") and the second (with "w") so
that the file, which *did not exist* at the time of the first
fopen(), *does* exist at the time of the second.
In particular, consider, on a Unix-like system, what happens if
you "race" your program against another one that does:
/* evilprogram.c */
#include <unistd.h/* yes, non-ANSI */
#define sensitive_file "/home/user/very_important_data"
#define name "whatever"
int main(void) {
for (;;) {
(void) unlink(name);
usleep(1);
(void) symlink(sensitive_file, name);
sleep(1);
}
/*NOTREACHED*/
}
Now, if "evilprogram" runs at the right (wrong?) time while it
races against your program, your code will do:
fp = fopen(name, "r");
and get NULL, because the file named "whatever" does not exist.
Then evilprogram runs and creates the symlink, so that the file
named "whatever" refers to your "very_important_data" file (or,
in the case of the security holes I mentioned earlier, perhaps
something like "/etc/passwd"). Since, in your code, fp==NULL,
you assume that the file named "whatever" *still* does not
exist, and you do:
fp = fopen(name, "w");
and are now overwriting your very important data (or /etc/passwd,
if running as root, e.g.).
(This problem existed before symlinks: since typical systems at
the time had /etc and /tmp on the same file system, one could make
a hard link from /etc/passwd to /tmp/foo and trick a setuid-root
program into writing on /tmp/foo, which was by then actually
/etc/passwd. The solution is to avoid the C library routines,
which are insufficient, and go directly to open() -- and, in the
case of setuid programs, to use the original 4.3BSD setreuid() or
the more modern POSIX-style saved-setuid -- not the original,
broken, System V version, which did not work for the super-user --
to "give up" setuid permissions temporarily. Fundamentally, what
is needed is an atomic "test all permissions and, only if OK, then
do the open" call. This just does not exist in Standard C.)
There really are times one can, and even should, write non-Standard-C
code. The trick is knowing when. :-)
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.
"Army1987" <pl********@for.itwrote:
# Now if it is possible that out = fopen(out_name, "r"); fclose(out); deletes
# the file, I'd better find another way...
<stdio.his sort of greatest common factor programming
amongst all possible C implementation. It's grossly unsuitable
for detailed I/O provided on various systems, by design.
You can beat your head against a wall or decide that you don't
want to program on all possible systems, just a subset. At that
point you can depend on other standards like SVID, and you get
additional operations which can do exactly this.
For example if you're willing to restrict yourself to Unix
and perhaps a few other systems, you can do an open(2) with
O_EXCL followed by an fdopen(3). I'm sure VMS also provides
this functionality in a completely different manner. Mac
System 7 also provided this functionality (preserved in Carbon),
again in completely different manner.
--
SM Ryan http://www.rawbw.com/~wyrmwif/
God's a skeeball fanatic.
SM Ryan said:
"Army1987" <pl********@for.itwrote:
# Now if it is possible that out = fopen(out_name, "r"); fclose(out);
# deletes the file, I'd better find another way...
<stdio.his sort of greatest common factor programming
amongst all possible C implementation. It's grossly unsuitable
for detailed I/O provided on various systems, by design.
How are you going to do I/O /without/ it, in a portable manner?
You can beat your head against a wall or decide that you don't
want to program on all possible systems, just a subset.
Which subset?
At that
point you can depend on other standards like SVID,
Is that available for *all* possible subsets of all possible systems?
and you get
additional operations which can do exactly this.
For example if you're willing to restrict yourself to Unix
....you can use comp.unix.programmer. That's what it's for.
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk
email: rjh at the above domain, - www.
Richard Heathfield <rj*@see.sig.invalidwrote:
# How are you going to do I/O /without/ it, in a portable manner?
I'm not part of your inbred clique.
--
SM Ryan http://www.rawbw.com/~wyrmwif/
A bunch of savages in this town.
On Sun, 8 Apr 2007 16:09:22 +0200, "Army1987" <pl********@for.it>
wrote:
>"Richard Heathfield" <rj*@see.sig.invalidha scritto nel messaggio
news:E4******************************@bt.com...
>Army1987 said:
<snip>
>>Now if it is possible that out = fopen(out_name, "r"); fclose(out);
deletes the file, I'd better find another way...
Well, I wouldn't expect that to happen! But I would not be surprised by
the following sequence of events:
1) you open the file read-only
2) you close the file
3) another process deletes the file
4) you act on your belief that the file exists
Multi-user / multi-process systems can be tricky, can't they?
Probably, in this very case it wouldn't harm so much, because I meant to do
something like:
#include <stdio.h>
#include <stdlib.h>
int ask(const char *prompt);
typedef char filename[FILENAME_MAX];
int main(int argc, char *argv[])
{
char *name;
FILE *in, *out;
filename in_name, out_name;
int overwrite = 0;
/* get filenames */
in = fopen(in_name, "r");
if (in == NULL) {
perror("Unable to read from file");
exit(EXIT_FAILURE);
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_FAILURE);
}
name = overwrite ? tmpnam(NULL) : out;
I assume you meant out_name here.
Isn't the test backwards?
out = fopen(name, "w");
if (out == NULL) {
fclose(in);
perror(overwrite ? "Unable to create temporary file"
: "Unable to create destination file");
exit(EXIT_FAILURE);
}
/* do stuff */
fclose(in);
if (fclose(out)) {
perror(overwrite ? "Unable to close temporary file"
: "Unable to close destination file");
exit(EXIT_FAILURE);
}
if (overwrite) {
if (remove(in_name)) {
Didn't you mean out_name throughout this overwrite logic?
perror("Unable to overwrite destination file");
fprintf("The temporary file is available as %s", name);
exit(EXIT_FAILURE);
}
if (rename(name, in_name)) {
perror("Unable to rename temporary file");
fprintf("The temporary file is available as %s", name);
exit(EXIT_FAILURE);
}
}
return EXIT_SUCCESS; /* Finally... */
}
(The actual error messages are just examples, I would use fprintf so to
include filenames.)
The very worst thing that could happen is that the destination filename
would have a wrong, temporary name, which the user would know so to rename
it by hand... or is it?
Remove del for email
SM Ryan said:
Richard Heathfield <rj*@see.sig.invalidwrote:
# How are you going to do I/O /without/ it, in a portable manner?
I'm not part of your inbred clique.
Neither am I. But I note that you avoid the question instead of
answering it.
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk
email: rjh at the above domain, - www.
"Barry Schwarz" <sc******@doezl.netha scritto nel messaggio
news:p3********************************@4ax.com...
> 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 Heathfield" <rj*@see.sig.invalidha scritto nel messaggio
news:AJ******************************@bt.com...
How are you going to do I/O /without/ it, in a portable manner?
<ot>
Not portable everywhere, but
#include <stdlib.h>
#include <string.h>
#define MAX 4090
int main(void)
{
char cmd[MAX+6] = "echo ";
system(strncat(cmd, "Hello, World!", MAX));
return 0;
}
should work on several systems. Input is trickier... :-) </ot>
Eric Sosman <es*****@acm-dot-org.invalidwrote:
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.DAT 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
Richard Bos wrote:
Eric Sosman <es*****@acm-dot-org.invalidwrote:
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.hshould have provided a function for that.
If you mean that some systems supporting <stdio.hfunctionality 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"?
Richard Bos wrote:
Eric Sosman <es*****@acm-dot-org.invalidwrote:
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.hshould have provided a function for that.
If you mean that some systems supporting <stdio.hfunctionality 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"?
Harald van D?k wrote:
[...]
If you mean that some systems supporting <stdio.hfunctionality 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
"cryptographic 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 wrote:
In article <46***************@spamcop.net>,
Kenneth Brody <ke******@spamcop.netwrote:
I seem to recall that someone posted several months back about a
"cryptographic 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. This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Phil Lamey |
last post by:
Hi Folks,
I have run into a bit of an issue with checking for files.
Some files reside on Server X and some on Server Y.
The page with all the links is on Server X. If the file exists we...
|
by: Geiregat Jonas |
last post by:
is using
if(open("file",O_EXCL) != -1){ printf("File does
exists")}else{printf("file does not exists"); }
a good way of checking if a file exists or not, if not how should I do it ?
|
by: Daz |
last post by:
Would anyone know of a way to check whether or not a particular path is
a directory? If I have to go down the route of using _findfirst and
_findnext (windows specific), then so be it. However, I...
|
by: darkslide |
last post by:
Hi,
I'm checking if a file exists with the following code;
If System.IO.File.Exists("C:\test.txt") = True Then
MsgBox("File Exists")
Else
MsgBox("File Does Not Exist")
End If
...
|
by: sprash |
last post by:
Newbie question:
I'm trying to determine if a file physically exists regardless of the
permissions on it
Using File.Exists() returns false if it physically exists but the
process does not...
|
by: mengesb |
last post by:
I'm looking to utilize something to the effect of this code:
ps -ef | grep sc_serv | grep -v grep | awk '{print $2}' > sc_serv.pid
cat sc_serv.pid
3447
3449
The first id it spits out is the...
|
by: timexsinclair2068 |
last post by:
This is a very simple question. Is there a simple,short way of
checking if the application's App.Config file exists?
Thanks!
|
by: winningElevent |
last post by:
Hi everyone,
I have a question would like to ask. So far I know how to retrieve files from device, but sometimes device takes so long to produce file so I want my desktop to keep checking every...
|
by: ndedhia1 |
last post by:
Hi.
I am writing a java program in which I want to ftp a file to another unix box.
First I have to check if the directory exists in which I am ftping into and if it does not exist, I have to create...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: aa123db |
last post by:
Variable and constants
Use var or let for variables and const fror constants.
Var foo ='bar';
Let foo ='bar';const baz ='bar';
Functions
function $name$ ($parameters$) {
}
...
|
by: ryjfgjl |
last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
| |
