How to detect an empty file?

[Olivier]

Dear all,

I thought the code
-----------------------------
pt_fichier_prob leme = fopen(nom_fichi er, "w");

if(pt_fichier_p robleme == NULL){
message_warning _s
("Erreur l'ouverture du fichier\n%s\n", (gchar *)nom_fichier);
return;}
else {
rewind(pt_fichi er_probleme); /* Be sure we're at beginning */
if(feof(pt_fich ier_probleme) == 0){
/* We are not at end of buffer ... It means the
file already has some content!! */
if( AskConfirmation (user_data) == 0){
/* L'utilisateur ne veut pas qu'on ecrive sur le fichier !!*/
fclose(pt_fichi er_probleme);
return;};
};};
-----------------------------

was an excellent way of
-- opening the file nom_fichier for writing,
-- detecting a mistake if it was not possible,
-- if the file was not empty, the askign the
user whether it still wants to overwrite it.
(that's AskConfirmation : a window with the question and so on)
As it turns out, confirmation is always asked :-(

Help?
Best !
Amities,
Olivier

[Tom St Denis]

Olivier wrote:

Dear all,

I thought the code

<snip>

OT but ... just use stat(). It will tell you

a) if the file or directory exists
b) What sort of entry is it [file, directory, symlink, pipe, etc]
c) The size

Peace!

Tom

[Walter Roberson]

In article <11************ *********@b28g2 000cwb.googlegr oups.com>,
Tom St Denis <to********@gma il.comwrote:

>OT but ... just use stat(). It will tell you

>a) if the file or directory exists
b) What sort of entry is it [file, directory, symlink, pipe, etc]
c) The size

stat() is not part of standard C. Neither are directories, symlinks,
pipes, "etc".
--
There are some ideas so wrong that only a very intelligent person
could believe in them. -- George Orwell

[attn.steven.kuo]

Olivier wrote:

Dear all,

I thought the code
-----------------------------
pt_fichier_prob leme = fopen(nom_fichi er, "w");

Opening the file in "w" mode truncates
the file to zero length if fopen was successful,
so there's no need to check for file size afterward.

Perhaps you were thinking of opening the file
in "r+" mode?

if(pt_fichier_p robleme == NULL){
message_warning _s
("Erreur l'ouverture du fichier\n%s\n", (gchar *)nom_fichier);
return;}
else {
rewind(pt_fichi er_probleme); /* Be sure we're at beginning */
if(feof(pt_fich ier_probleme) == 0){
/* We are not at end of buffer ... It means the
file already has some content!! */
if( AskConfirmation (user_data) == 0){
/* L'utilisateur ne veut pas qu'on ecrive sur le fichier !!*/
fclose(pt_fichi er_probleme);
return;};
};};
-----------------------------

was an excellent way of
-- opening the file nom_fichier for writing,
-- detecting a mistake if it was not possible,
-- if the file was not empty, the askign the
user whether it still wants to overwrite it.
(that's AskConfirmation : a window with the question and so on)
As it turns out, confirmation is always asked :-(

Determine the difference in file position between
the start and end of the file with 'fseek' and 'ftell'.

--
Hope this helps,
Steven

[Tom St Denis]

Walter Roberson wrote:

In article <11************ *********@b28g2 000cwb.googlegr oups.com>,
Tom St Denis <to********@gma il.comwrote:

OT but ... just use stat(). It will tell you

a) if the file or directory exists
b) What sort of entry is it [file, directory, symlink, pipe, etc]
c) The size

stat() is not part of standard C. Neither are directories, symlinks,
pipes, "etc".

I recognized that by saying "OT" so pointing this out is redundant. No
reason I can't give the dude a three second tip. Tell the dude it's OT
and then point them in the right direction. In theory, you've not only
helped them but helped clear up the group.

Just replying to someone that has already acknowledged that it's OT
with a comment about it being OT is pathetic and lame.

Tom

[Walter Roberson]

In article <44************ **********@news .free.fr>,
Olivier <Ol**@nowhere.w dwrote:

>pt_fichier_pro bleme = fopen(nom_fichi er, "w");

>if(pt_fichier_ probleme == NULL){
message_warning _s
("Erreur l'ouverture du fichier\n%s\n", (gchar *)nom_fichier);
return;}
else {
rewind(pt_fichi er_probleme); /* Be sure we're at beginning */
if(feof(pt_fich ier_probleme) == 0){
/* We are not at end of buffer ... It means the
file already has some content!! */

Two mistakes:

1) Using "w" tells fopen() to truncate the file to zero length if it
exists. Use "r+" (or "r+b") instead.

2) feof() is not set until at least one character of I/O is attempted.
You could -try- to fseek() to the end of the file. If you do that on
a text stream, the result will be a [theoretically] opaque position,
but on a binary stream ("r+b") the fseek() result can be read off
directly in characters and so can be meaningfully compared to 0.

Note: If you need to open in binary to do the fseek() test then you
can always freopen() later without the "b" flag if you really want
to work with text instead of binary.
--
All is vanity. -- Ecclesiastes

[Walter Roberson]

In article <11************ **********@s13g 2000cwa.googleg roups.com>,
Tom St Denis <to********@gma il.comwrote:

>
Walter Roberson wrote:

>In article <11************ *********@b28g2 000cwb.googlegr oups.com>,
Tom St Denis <to********@gma il.comwrote:

>OT but ... just use stat(). It will tell you

>stat() is not part of standard C. Neither are directories, symlinks,
pipes, "etc".

>I recognized that by saying "OT" so pointing this out is redundant. No
reason I can't give the dude a three second tip. Tell the dude it's OT
and then point them in the right direction. In theory, you've not only
helped them but helped clear up the group.

Except you haven't helped the OP, because stat() does not exist in
all systems. The code the OP gave had no clue as to which operating system
was in use. For example in a number of versions of MS Windows, the
closest equivilent would be one of the _stat*() calls.

Your proposed solution also would require that the user open
the file-descriptor can of worms: you could have at least said fstat()
to be closer to the normal C I/O library.
When you give OT answers, you should at the very least qualify them
by naming the solution domain (e.g., "Linux 3.2", "Windows NT and
later").
--
"It is important to remember that when it comes to law, computers
never make copies, only human beings make copies. Computers are given
commands, not permission. Only people can be given permission."
-- Brad Templeton

[Eric Sosman]

Olivier wrote On 07/10/06 15:05,:

Dear all,

I thought the code
-----------------------------
pt_fichier_prob leme = fopen(nom_fichi er, "w");

if(pt_fichier_p robleme == NULL){
message_warning _s
("Erreur l'ouverture du fichier\n%s\n", (gchar *)nom_fichier);
return;}
else {
rewind(pt_fichi er_probleme); /* Be sure we're at beginning */
if(feof(pt_fich ier_probleme) == 0){
/* We are not at end of buffer ... It means the
file already has some content!! */
if( AskConfirmation (user_data) == 0){
/* L'utilisateur ne veut pas qu'on ecrive sur le fichier !!*/
fclose(pt_fichi er_probleme);
return;};
};};
-----------------------------

was an excellent way of
-- opening the file nom_fichier for writing,

Yes, it does that.

-- detecting a mistake if it was not possible,

It does that, too.

-- if the file was not empty, the askign the
user whether it still wants to overwrite it.

Too late. If the file does not exist, fopen(...,"w")
creates a new, empty file. If the file exists already,
fopen(...,"w") makes it empty. Either way, the file is
empty after fopen() succeeds, and any data it might have
contained is gone.

(that's AskConfirmation : a window with the question and so on)
As it turns out, confirmation is always asked :-(

That is because feof() does not mean what you think
it does. feof() does not ask the question "Is the stream
positioned at the end of the file?" Rather, feof() asks
"Has the end of the file been reached?" Although these
seem similar (and are related), they are not quite the
same. A stream "reaches the end" of a file not by arriving
at the e-o-f position, but by trying (and failing) to go
past that position. In other words, feof() does not predict
whether the next I/O operation would occur at e-o-f, but
instead tells why an I/O operation failed: was it because
the operation tried to go past e-o-f, or was it for some
other reason (like a disk failure)?

If your fopen() succeeds, the stream is positioned at
the beginning of the empty file (which is also the end).
The rewind() presumably "succeeds" because it has nothing
to do: the stream is already at the start of the file.
You then ask feof() whether a previous I/O operation failed
by running off the end of the file; there has been no such
failure, so feof() says "No."

C has no perfect solution to your problem. One possibility
is to use fopen(...,"r") first, just to test whether the file
exists. If this fopen() succeeds, fclose() it and ask the
user for instructions; do fopen(...,"w") only if the user
chooses to overwrite the file. This is not bullet-proof for
a number of reasons: The first attempt might fail for some
reason other than "no such file," some other program might
create the file two microseconds after your program decides
that it doesn't exist, and so on. Still, it's about the best
you can do without resorting to system-specific code.

<off-topic>

A technique that works on POSIX systems is to open() the
file using the O_EXCL flag and then use fdopen() to attach a
C I/O stream to the resulting file descriptor.

</off-topic>

--
Er*********@sun .com

[Olivier]

[...]

C has no perfect solution to your problem. One possibility
is to use fopen(...,"r") first, just to test whether the file
exists. If this fopen() succeeds, fclose() it and ask the
user for instructions; do fopen(...,"w") only if the user
chooses to overwrite the file.

Thanks to all of you. That's the solution I've finally chosen
after having had a nice but aborted trip towards <sys/stat.h>
I just couldn't make that work. That's most probably for when
I'll be older :-p

Best !
Amities,
Olivier

[Bill Pursell]

Walter Roberson wrote:

In article <11************ **********@s13g 2000cwa.googleg roups.com>,
Tom St Denis <to********@gma il.comwrote:

Walter Roberson wrote:

In article <11************ *********@b28g2 000cwb.googlegr oups.com>,
Tom St Denis <to********@gma il.comwrote:

OT but ... just use stat(). It will tell you

stat() is not part of standard C. Neither are directories, symlinks,
pipes, "etc".

I recognized that by saying "OT" so pointing this out is redundant. No
reason I can't give the dude a three second tip. Tell the dude it's OT
and then point them in the right direction. In theory, you've not only
helped them but helped clear up the group.

Except you haven't helped the OP, because stat() does not exist in
all systems. The code the OP gave had no clue as to which operating system
was in use. For example in a number of versions of MS Windows, the
closest equivilent would be one of the _stat*() calls.

Tom's reply was more helpful than saying nothing. The OP can
certainly google for stat and fstat and at the very least discover
that they are unrelated to the platform of interest. In doing so,
the OP may discover that the platform of interest does contain
a stat()-like call of which he was formerly unaware. It is
entirely likely that the OP simply is not aware that functionality
such as stat is available, so Tom's answer is completely
appropriate.

When you give OT answers, you should at the very least qualify them
by naming the solution domain (e.g., "Linux 3.2", "Windows NT and
later").

Just out of curiousity, what is Linux 3.2? kernel.org shows 2.6.17.4
as
the most recent stable release...surel y you're not suggesting that
the OP use a radically unstable and indeed unheard of kernel?