By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,929 Members | 1,245 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,929 IT Pros & Developers. It's quick & easy.

file exists or not before calling fopen

P: n/a
Hi, there,

I am trying to append a binary file by using:

FILE *strean;

stream = fopen( "c:\temp.dat", "ba+" ));

Is there a way that I can check if the file exists or not before
fopen, because I will call different work flow by check the status of
the file?

Thanks in advance,

Feb 20 '07 #1
Share this Question
Share on Google+
10 Replies


P: n/a
"Julia" wrote:
>I am trying to append a binary file by using:

FILE *strean;

stream = fopen( "c:\temp.dat", "ba+" ));

Is there a way that I can check if the file exists or not before
fopen, because I will call different work flow by check the status of
the file?
You can attempt to open the file in read-only mode, and then open it
again for appending after you know the result of the first operation.
(Or use a system-specific mechanism to read the directory, etc.)

Be aware that if environment is a multi-tasking system, and the
existence of the file depends on another program, there is no way (in
standard C) of guaranteeing that the file was not created by somebody
else between the two fopen() calls.

Roberto Waltman

[ Please reply to the group,
return address is invalid ]
Feb 20 '07 #2

P: n/a
Julia wrote:
Hi, there,

I am trying to append a binary file by using:

FILE *strean;

stream = fopen( "c:\temp.dat", "ba+" ));
That's a very peculiar file name. You might want to
review Question 19.17 in the comp.lang.c Frequently Asked
Questions (FAQ) list at <http://c-faq.com/before you go
much further.
Is there a way that I can check if the file exists or not before
fopen, because I will call different work flow by check the status of
the file?
... and this is Question 19.11.

--
Eric Sosman
es*****@acm-dot-org.invalid
Feb 20 '07 #3

P: n/a

"Julia" <ju********@yahoo.comwrote in message
news:11**********************@a75g2000cwd.googlegr oups.com...
Hi, there,

I am trying to append a binary file by using:

FILE *strean;

stream = fopen( "c:\temp.dat", "ba+" ));

Is there a way that I can check if the file exists or not before
fopen, because I will call different work flow by check the status of
the file?

Thanks in advance,
After you call fopen with "ba+", use ftell to see where you are.
--
Fred L. Kleinschmidt
Boeing Associate Technical Fellow
Aero Stability and Controls Computing
Feb 20 '07 #4

P: n/a
"Fred Kleinschmidt" wrote:
>"Julia" wrote:
>>...
Is there a way that I can check if the file exists or not before
fopen, because I will call different work flow by check the status of
the file?
After you call fopen with "ba+", use ftell to see where you are.
That will not answer the OP question.
ftell() will return a zero offset both if the file was created by
fopen(), or if it existed already with a length of zero.

Roberto Waltman

[ Please reply to the group,
return address is invalid ]
Feb 20 '07 #5

P: n/a
On Tue, 20 Feb 2007 10:36:46 -0800, Julia wrote:
Hi, there,

I am trying to append a binary file by using:

FILE *strean;

stream = fopen( "c:\temp.dat", "ba+" ));

Is there a way that I can check if the file exists or not before
fopen, because I will call different work flow by check the status of
the file?

Thanks in advance,
Does it matter if between the existence test and the fopen() call the
status changes?
Feb 20 '07 #6

P: n/a
Julia <ju********@yahoo.comwrote:
I am trying to append a binary file by using:
stream = fopen( "c:\temp.dat", "ba+" ));
As an aside, I bet $100 you meant

stream = fopen( "c:\\temp.dat", "ba+" )); /* Note \\ */

Either that or you just learned why cutting and pasting is good.

--
C. Benson Manica | I *should* know what I'm talking about - if I
cbmanica(at)gmail.com | don't, I need to know. Flames welcome.
Feb 20 '07 #7

P: n/a
Eric Sosman wrote:
Julia wrote:
>>
I am trying to append a binary file by using:

FILE *strean;

stream = fopen( "c:\temp.dat", "ba+" ));

That's a very peculiar file name. You might want to review
Question 19.17 in the comp.lang.c Frequently Asked Questions
(FAQ) list at <http://c-faq.com/before you go much further.
She may be trying to create files that will drive others nuts
attempting to delete them :-)

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>

"A man who is right every time is not likely to do very much."
-- Francis Crick, co-discover of DNA
"There is nothing more amazing than stupidity in action."
-- Thomas Matthews
Feb 21 '07 #8

P: n/a
On Feb 20, 11:21 am, "Fred Kleinschmidt"
<fred.l.kleinmschm...@boeing.comwrote:
"Julia" <julia65...@yahoo.comwrote in message

news:11**********************@a75g2000cwd.googlegr oups.com...Hi, there,
I am trying to append a binary file by using:
FILE *strean;
stream = fopen( "c:\temp.dat", "ba+" ));
Is there a way that I can check if the file exists or not before
fopen, because I will call different work flow by check the status of
the file?
Thanks in advance,

After you call fopen with "ba+", use ftell to see where you are.
Don't forget Buckaroo Bonzai's "Wherever you go, there you are."

With modern file systems, there is a potential bug in fseek/ftell.
>From the C-FAQ:
12.25: What's the difference between fgetpos/fsetpos and ftell/fseek?
What are fgetpos() and fsetpos() good for?

A: ftell() and fseek() use type long int to represent offsets
(positions) in a file, and may therefore be limited to offsets
of about 2 billion (2**31-1). The newer fgetpos() and fsetpos()
functions, on the other hand, use a special typedef, fpos_t, to
represent the offsets. The type behind this typedef, if chosen
appropriately, can represent arbitrarily large offsets, so
fgetpos() and fsetpos() can be used with arbitrarily huge files.
fgetpos() and fsetpos() also record the state associated with
multibyte streams. See also question 1.4.

References: K&R2 Sec. B1.6 p. 248; ISO Sec. 7.9.1,
Secs. 7.9.9.1,7.9.9.3; H&S Sec. 15.5 p. 252.

And speaking of "can I tell if a file exists..." we have this:

19.11: How can I check whether a file exists? I want to warn the user
if a requested input file is missing.

A: It's surprisingly difficult to make this determination reliably
and portably. Any test you make can be invalidated if the file
is created or deleted (i.e. by some other process) between the
time you make the test and the time you try to open the file.

Three possible test functions are stat(), access(), and fopen().
(To make an approximate test using fopen(), just open for
reading and close immediately, although failure does not
necessarily indicate nonexistence.) Of these, only fopen() is
widely portable, and access(), where it exists, must be used
carefully if the program uses the Unix set-UID feature.

Rather than trying to predict in advance whether an operation
such as opening a file will succeed, it's often better to try
it, check the return value, and complain if it fails.
(Obviously, this approach won't work if you're trying to avoid
overwriting an existing file, unless you've got something like
the O_EXCL file opening option available, which does just what
you want in this case.)

References: PCS Sec. 12 pp. 189,213; POSIX Sec. 5.3.1,
Sec. 5.6.2, Sec. 5.6.3.

Let's not forget that fopen() and stat() can also fail for permission
reasons (and others for sure, which I can't think of right now, but
which are probably pertinant).

Isn't anybody going to tell the poor suffering OP about his escaped t
that looks a bit like a backslash and a 't' but isn't? OK, I will.
No, I'll let the FAQ do it:

19.17: Why can't I open a file by its explicit path? The call

fopen("c:\newdir\file.dat", "r")

is failing.

A: The file you actually requested -- with the characters \n and \f
in its name -- probably doesn't exist, and isn't what you
thought you were trying to open.

In character constants and string literals, the backslash \ is
an escape character, giving special meaning to the character
following it. In order for literal backslashes in a pathname to
be passed through to fopen() (or any other function) correctly,
they have to be doubled, so that the first backslash in each
pair quotes the second one:

fopen("c:\\newdir\\file.dat", "r")

Alternatively, under MS-DOS, it turns out that forward slashes
are also accepted as directory separators, so you could use

fopen("c:/newdir/file.dat", "r")

(Note, by the way, that header file names mentioned in
preprocessor #include directives are *not* string literals, so
you may not have to worry about backslashes there.)

No wonder so many people are saying things like "Read the FAQ!" and
"FAQ for president!" and stuff like that.
--
Fred L. Kleinschmidt
Boeing Associate Technical Fellow
Aero Stability and Controls Computing

Feb 21 '07 #9

P: n/a
CBFalconer wrote:
Eric Sosman wrote:
>Julia wrote:
>>I am trying to append a binary file by using:

FILE *strean;

stream = fopen( "c:\temp.dat", "ba+" ));
That's a very peculiar file name. You might want to review
Question 19.17 in the comp.lang.c Frequently Asked Questions
(FAQ) list at <http://c-faq.com/before you go much further.

She may be trying to create files that will drive others nuts
attempting to delete them :-)
<off-topic>

On some systems, the filenames "*" and "-rf *" are
especially amusing ...

</off-topic>

--
Eric Sosman
es*****@acm-dot-org.invalid
Feb 21 '07 #10

P: n/a
Eric Sosman wrote:
>
CBFalconer wrote:
[...]
She may be trying to create files that will drive others nuts
attempting to delete them :-)

<off-topic>

On some systems, the filenames "*" and "-rf *" are
especially amusing ...
On similar platforms, embedding the sequence '\033' '[' 'D' in the
filename can lead to amusing things as well.
</off-topic>

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

Feb 21 '07 #11

This discussion thread is closed

Replies have been disabled for this discussion.