How to detect an empty file?

[Olivier]

Dear all,

I thought the code
-----------------------------
pt_fichier_probleme = fopen(nom_fichier, "w");

if(pt_fichier_probleme == NULL){
message_warning_s
("Erreur l'ouverture du fichier\n%s\n", (gchar *)nom_fichier);
return;}
else {
rewind(pt_fichier_probleme); /* Be sure we're at beginning */
if(feof(pt_fichier_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_fichier_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*********************@b28g2000cwb.googlegroups. com>,
Tom St Denis <to********@gmail.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_probleme = fopen(nom_fichier, "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_probleme == NULL){
message_warning_s
("Erreur l'ouverture du fichier\n%s\n", (gchar *)nom_fichier);
return;}
else {
rewind(pt_fichier_probleme); /* Be sure we're at beginning */
if(feof(pt_fichier_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_fichier_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*********************@b28g2000cwb.googlegroups. com>,
Tom St Denis <to********@gmail.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.wdwrote:

>pt_fichier_probleme = fopen(nom_fichier, "w");

>if(pt_fichier_probleme == NULL){
message_warning_s
("Erreur l'ouverture du fichier\n%s\n", (gchar *)nom_fichier);
return;}
else {
rewind(pt_fichier_probleme); /* Be sure we're at beginning */
if(feof(pt_fichier_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**********************@s13g2000cwa.googlegroups .com>,
Tom St Denis <to********@gmail.comwrote:

>
Walter Roberson wrote:

>In article <11*********************@b28g2000cwb.googlegroups. com>,
Tom St Denis <to********@gmail.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_probleme = fopen(nom_fichier, "w");

if(pt_fichier_probleme == NULL){
message_warning_s
("Erreur l'ouverture du fichier\n%s\n", (gchar *)nom_fichier);
return;}
else {
rewind(pt_fichier_probleme); /* Be sure we're at beginning */
if(feof(pt_fichier_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_fichier_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**********************@s13g2000cwa.googlegroups .com>,
Tom St Denis <to********@gmail.comwrote:

Walter Roberson wrote:

In article <11*********************@b28g2000cwb.googlegroups. com>,
Tom St Denis <to********@gmail.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...surely you're not suggesting that
the OP use a radically unstable and indeed unheard of kernel?

[Keith Thompson]

"Tom St Denis" <to********@gmail.comwrites:

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

I see you've pointed out that this is off-topic (assuming that the
original poster understands that OT means "off-topic"), but you
haven't given a clue about *why* it's off-topic.

The stat() function is not part of the standard C library. It's
defined by POSIX. It should be available on all Unix and Unix-like
systems, and it's likely to be available on many other systems as well
(probably including Windows, but I'm not certain) -- but any code that
uses it will be less portable than code that restricts itself to the
standard C library. The loss of portability may or may not be an
acceptable price to pay for the convenience of using the stat()
function.

It's also important to remember that any function that gives you
information about a file can only give you information as of the time
it's called. It's entirely possible that you could call stat(), find
out that the file doesn't exist, and then try to create it, only to
find out that something else created the file between the stat() call
and the fopen() call. It may or may not be acceptable to ignore this
possibility.

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

[solariun]

So.. how are you don´t want to use a beatiful way (stat) try it:

fopen

x = lseek (pFile, 0, SEEK_END);

and test if x is igual top zero ou -1 (in case of error). But if zero
is returned, it´s mean that file is zero... This example can work in
every where where have a full implamentation of C standards but i will
warning you, it´s a ugly way to write this kind of procedure because
even you are using a M$ Visual C++, you can use stast. unless you are
using a DOS Turbo C of corse.

Have a good trip through it!

Olivier escreveu:

Dear all,

I thought the code
-----------------------------
pt_fichier_probleme = fopen(nom_fichier, "w");

if(pt_fichier_probleme == NULL){
message_warning_s
("Erreur l'ouverture du fichier\n%s\n", (gchar *)nom_fichier);
return;}
else {
rewind(pt_fichier_probleme); /* Be sure we're at beginning */
if(feof(pt_fichier_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_fichier_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

[Keith Thompson]

so******@gmail.com writes:

So.. how are you don´t want to use a beatiful way (stat) try it:

fopen

x = lseek (pFile, 0, SEEK_END);

and test if x is igual top zero ou -1 (in case of error). But if zero
is returned, it´s mean that file is zero... This example can work in
every where where have a full implamentation of C standards but i will
warning you, it´s a ugly way to write this kind of procedure because
even you are using a M$ Visual C++, you can use stast. unless you are
using a DOS Turbo C of corse.

lseek() is not a standard C function. You're probably thinking of
fseek().

Note that the standard makes fewer guarantees about the behavior of
fseek() than you might expect. In particular:

For a text stream, the offset argument needs to be either zero or
the result of an earlier call to ftell().

For a binary stream, fseek() with SEEK_END isn't guaranteed to be
meaningful. (An implementation may pad a binary file with bytes
with zero values, but the standard doesn't even make the
guarantees that that might imply for fseek().)

See the C standard (or n1124.pdf) for details.

It's possible that you can get away with assuming more than the
standard guarantees (<OT>for example, on a Unix system, file offsets
are simple byte counts for both text and binary files</OT>), but by
depending on these things you make your code potentially non-portable.

The obvious way to tell whether a file is empty is to attempt to read
a byte from it; if the attempt fails (e.g., fgetc() returns EOF), then
there was nothing to read -- or there was an error. (You can use
feof() and/or ferror() *after* this to determine why the attempt
failed.)

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

[Eric Sosman]

so******@gmail.com wrote On 07/10/06 16:45,:

So.. how are you don´t want to use a beatiful way (stat) try it:

fopen

x = lseek (pFile, 0, SEEK_END);

and test if x is igual top zero ou -1 (in case of error). But if zero
is returned, it´s mean that file is zero... This example can work in
every where where have a full implamentation of C standards but i will
warning you, it´s a ugly way to write this kind of procedure because
even you are using a M$ Visual C++, you can use stast. unless you are
using a DOS Turbo C of corse.

This is nonsense. lseek() is not part of the C Standard
library, and a "full implamantation [sic] of C standards" need
not provide lseek().

<off-topic>

POSIX systems provide an lseek(), but it does not solve
the O.P.'s problem. For one thing, its first argument is not
a FILE*, as the code snippet above suggests. For another, it
does magically go back in time to undo fopen()'s truncation
of a pre-existing file. For a third, it still doesn't address
the issue of other programs creating files just after you've
decided they don't exist.

POSIX has ways to solve the problem, but lseek() is not
part of the solution.

</off-topic>

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

[Keith Thompson]

so******@gmail.com writes:

So.. how are you don´t want to use a beatiful way (stat) try it:

fopen

x = lseek (pFile, 0, SEEK_END);

[snip]

Something I forgot to mention in my previous followup:

Please don't top-post. See <http://www.caliburn.nl/topposting.html>
(and most of the articles in this newsgroup) for details.

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

[Dann Corbit]

What happens if someone else appends data after you fseek()?

I don't think that the question has an answer.

[Tom St Denis]

Walter Roberson wrote:

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.

stat() works on paths not file descriptors. If you're alluding to race
conditions all file routines have them.

BTW saying "stat" isn't portable is kinda moot since not all platforms
have files anyways.

But even Windows has "stat" like functionality. BSD, MacOs, Linuxes
have it too. So do UNIXes. So very likely using some stat function is
better than opening the file and doing some ftell crap.

Tom

[Keith Thompson]

"Tom St Denis" <to********@gmail.comwrites:

Walter Roberson wrote:

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

stat() works on paths not file descriptors. If you're alluding to race
conditions all file routines have them.

BTW saying "stat" isn't portable is kinda moot since not all platforms
have files anyways.

Not at all. There's a very real difference between functions that are
defined in the C standard (and are therefore guaranteed to be
available on all conforming hosted implementations) and functions that
are defined in some other standard (and are therefore guaranteed to be
available only on implementations that conform to that standard).

But even Windows has "stat" like functionality. BSD, MacOs, Linuxes
have it too. So do UNIXes. So very likely using some stat function is
better than opening the file and doing some ftell crap.

There's a big difference between supporting the stat() function as
defined by the POSIX standard, and having "stat" like functionality.
If Windows has function that's similar to stat(), but that has a
different name and/or different semantics, then that function can't be
used in portable code. ftell() can (though there are limits to what's
guaranteed for ftell()).

And there are systems other than BSD, MacOS, Linux, and Windows. Does
OpenVMS support stat()? What about IBM's various mainframe operating
systems? (Those are rhetorical questions, BTW.)

Sometimes a non-portable solution is the best one, but it's important
to know what's part of the C standard and what isn't, and to know just
what tradeoffs you're making.

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

[Dann Corbit]

"Tom St Denis" <to********@gmail.comwrote in message
news:11**********************@p79g2000cwp.googlegr oups.com...

Walter Roberson wrote:

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

stat() works on paths not file descriptors. If you're alluding to race
conditions all file routines have them.

BTW saying "stat" isn't portable is kinda moot since not all platforms
have files anyways.

But even Windows has "stat" like functionality. BSD, MacOs, Linuxes
have it too. So do UNIXes. So very likely using some stat function is
better than opening the file and doing some ftell crap.

Even at that, I don't think that any of them (techniques like stat()) work
on any of the systems mentioned.

Windows, BSD, MacOs, Linuxes, UNIXes, etc. all allow more than one thread or
process to open a given file.

Therefore, stat(), fseek(), etc. cannot give the requested answer because it
can change between the time you ask the question and the time that you use
the information returned by the inquiry.

I think a better idea is to find out what is supposed to be accomplished and
then come up with a portable solution.

IMO-YMMV.

[Old Wolf]

at*************@gmail.com wrote:

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

He's opening the file in text mode, so this method won't work.

[Keith Thompson]

"Old Wolf" <ol*****@inspire.net.nzwrites:

at*************@gmail.com wrote:

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

He's opening the file in text mode, so this method won't work.

To be painfully precise, it's not *guaranteed* to work. (It actually
will work on some systems -- which is probably worse than not working
at all.)

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

[Chris Torek]

>Walter Roberson wrote:

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

In article <11**********************@p79g2000cwp.googlegroups .com>
Tom St Denis <to********@gmail.comwrote:

>stat() works on paths not file descriptors. If you're alluding to race
conditions all file routines have them.

Not *all*: open() with O_CREAT|O_EXCL, for instance, does not.
Indeed, this is the *only* way to guarantee that a file that did
not exist before the call is created by the call and does exist
after the call.

Similarly, open() followed by fstat() avoids some (but not all)
races: in particular, the information you get with fstat() will
definitely refer to the underlying file, and the st_ino, st_dev,
and st_rdev fields should not change (of course the size, owner,
and permissions, for instance, could change).

>BTW saying "stat" isn't portable is kinda moot since not all platforms
have files anyways.

While the latter is true, the former is an overstatement: there are
hosted systems that have "files" dealt with via fopen, but lack
the stat() family of calls (e.g., C on some Univac and IBM sysems).

>But even Windows has "stat" like functionality. BSD, MacOs, Linuxes
have it too. So do UNIXes. So very likely using some stat function is
better than opening the file and doing some ftell crap.

Usually it is best to open() the file, then use fstat() if needed.
On many systems, this is essentially just as fast as using stat()
on the file, too; and if you intend to open it after getting the
result from stat(), open() followed by fstat() is faster -- often
significantly faster -- than stat() followed by open(). The reason
is that most of the work (and hence most of the time) goes to
translating path names, rather than dealing with the final on-media
entity representing the file. Doing stat(), then open(), runs the
slow code twice; doing open(), then fstat(), runs it only once.

(On vxWorks, stat() is in fact implemented as open() followed by
fstat() followed by close(). So here it is *definitely* more
efficient to open() first, then fstat().)
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

[Keith Thompson]

Chris Torek <no****@torek.netwrites:

>>Walter Roberson wrote:

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

In article <11**********************@p79g2000cwp.googlegroups .com>
Tom St Denis <to********@gmail.comwrote:

>>stat() works on paths not file descriptors. If you're alluding to race
conditions all file routines have them.

Not *all*: open() with O_CREAT|O_EXCL, for instance, does not.
Indeed, this is the *only* way to guarantee that a file that did
not exist before the call is created by the call and does exist
after the call.

[...]

Not entirely topical, but ...

According to the Linux man page for open(2):

O_EXCL is broken on NFS file systems, programs which rely on it
for performing locking tasks will contain a race condition.

It suggests an alternative, but it's even more off-topic than O_EXCL,
so I'll leave it to anyone interested in the details to look it up.

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

[Chris Torek]

(More off-topic drift; I plan to stop adding to it after this :-) )

>Chris Torek <no****@torek.netwrites:

>... open() with O_CREAT|O_EXCL, for instance, [avoids certain races on

POSIX systems].

In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.orgwrote:

>Not entirely topical, but ...

According to the Linux man page for open(2):

O_EXCL is broken on NFS file systems, programs which rely on it
for performing locking tasks will contain a race condition.

This is (at least theoretically) fixed in modern versions of NFS,
which use a "create verifier" to make the "idempotent but unrepeatable
due to O_EXCL" operation repeatable (hence "really" idempotent).

The client and server both have to support at least v3, and both
have to implement create-verifiers. Not all NFS-es do so, alas.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

[Clever Monkey]

Keith Thompson wrote:

"Tom St Denis" <to********@gmail.comwrites:

[...]

>But even Windows has "stat" like functionality. BSD, MacOs, Linuxes
have it too. So do UNIXes. So very likely using some stat function is
better than opening the file and doing some ftell crap.

There's a big difference between supporting the stat() function as
defined by the POSIX standard, and having "stat" like functionality.
If Windows has function that's similar to stat(), but that has a
different name and/or different semantics, then that function can't be
used in portable code. ftell() can (though there are limits to what's
guaranteed for ftell()).

And there are systems other than BSD, MacOS, Linux, and Windows. Does
OpenVMS support stat()? What about IBM's various mainframe operating
systems? (Those are rhetorical questions, BTW.)

If we were looking for an answer, I can supply one. Many IBM mainframes
only have stat() and other POSIX (or POSIX-like) routines if they are
supplied as an add-on. IBM has such routines for the 390, at least in
part, because a company I worked for supplied them.

Sometimes a non-portable solution is the best one, but it's important
to know what's part of the C standard and what isn't, and to know just
what tradeoffs you're making.

Point taken.

[Joe Wright]

Olivier wrote:

Dear all,

I thought the code
-----------------------------
pt_fichier_probleme = fopen(nom_fichier, "w");

if(pt_fichier_probleme == NULL){
message_warning_s
("Erreur l'ouverture du fichier\n%s\n", (gchar *)nom_fichier);
return;}
else {
rewind(pt_fichier_probleme); /* Be sure we're at beginning */
if(feof(pt_fichier_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_fichier_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

long sof(FILE *f) {
long end, her = ftell(f);
fseek(f, 0, SEEK_END);
end = ftell(f);
fseek(f, her, SEEK_SET);
return end;
}

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

[Joe Wright]

Olivier wrote:

Dear all,

I thought the code
-----------------------------
pt_fichier_probleme = fopen(nom_fichier, "w");

if(pt_fichier_probleme == NULL){
message_warning_s
("Erreur l'ouverture du fichier\n%s\n", (gchar *)nom_fichier);
return;}
else {
rewind(pt_fichier_probleme); /* Be sure we're at beginning */
if(feof(pt_fichier_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_fichier_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

long sof(FILE *f) {
long end, her = ftell(f);
fseek(f, 0, SEEK_END);
end = ftell(f);
fseek(f, her, SEEK_SET);
return end;
}

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

[Walter Roberson]

In article <w4******************************@comcast.com>,
Joe Wright <jo********@comcast.netwrote:

>long sof(FILE *f) {
long end, her = ftell(f);
fseek(f, 0, SEEK_END);
end = ftell(f);
fseek(f, her, SEEK_SET);
return end;
}

Small problems:

1) fseek() undoes any ungetc()

2) You haven't really defined what the return value means.
If f is a text stream, then the value returned by ftell() is
opaque. Looking at the man page I have handy, I can't tell if
it is even certain to be non-zero for non-empty files

3) You don't check the return value from fseek(SEEK_END) so you
are not certain that the fseek() has succeeded. Your value
"end" might be the same as your value "her", rather than reflecting
the position of the end of file or signalling that the
position is not meaningful (e.g., for a device).
--
Is there any thing whereof it may be said, See, this is new? It hath
been already of old time, which was before us. -- Ecclesiastes

[ritesh]

While going through this thread and writting some of my own code I
noticed this -

1. Suppose I create a text file. Write some data to it. Then close
the FILE* pointer to this file.
2. Since I have the path for the file (as char *), I can always open
the file in append mode to write more data to it.
3. What if I want to open the file in "edit" mode, and need to insert
text at the beginning of the file?

If I open using -
filePtr = fopen(filePath, "wt");
then the file is truncated to zero length and I loose the previous
data.

If I open using
filePtr = fopen(filePath, "at");
then the file pointer is placed at the end of the file. If I try to
this -
rewind(filePtr);
now the filePtr moves to end of the file, since it was opened in append
mode and it allow me to move back anymore.

I guess the only option left is to -
long int length = someFunctionToGetLengthOfFile(filePtr);
fseek(filePtr, -length, SEEK_SET);

Could someone please tell me which function would give me the length of
the text file? Portable solutions would be best, non-portable would do
as long as they work on Linux, Unix and Solaris.

Thanks,
Ritesh

[Keith Thompson]

"ritesh" <ri**********@gmail.comwrites:

While going through this thread and writting some of my own code I
noticed this -

1. Suppose I create a text file. Write some data to it. Then close
the FILE* pointer to this file.
2. Since I have the path for the file (as char *), I can always open
the file in append mode to write more data to it.
3. What if I want to open the file in "edit" mode, and need to insert
text at the beginning of the file?

There's no standard way to do that, and very likely no system-specific
way to do it directly. The usual way to do that kind of thing is to
create a new file, write the new data to it, then copy the old file,
the rename the new file to the old file's name.

If I open using -
filePtr = fopen(filePath, "wt");
then the file is truncated to zero length and I loose the previous
data.

If I open using
filePtr = fopen(filePath, "at");
then the file pointer is placed at the end of the file. If I try to
this -
rewind(filePtr);
now the filePtr moves to end of the file, since it was opened in append
mode and it allow me to move back anymore.

Both "wt" and "at" are non-standard. The only standard mode arguments
for fopen() are:

r w a
rb wb ab
r+ w+ a+
r+b w+b a+b (or rb+ wb+ ab+)

I guess the only option left is to -
long int length = someFunctionToGetLengthOfFile(filePtr);
fseek(filePtr, -length, SEEK_SET);

Could someone please tell me which function would give me the length of
the text file? Portable solutions would be best, non-portable would do
as long as they work on Linux, Unix and Solaris.

The only portable way to get the length of a text file is to read the
whole file and count the characters. (On some systems, this won't be
the physical size of the file; for example, on Windows each
two-character CR LF end-of-line marker is translated to a single '\n'
-- but only in text mode.)

Non-portably, you might be able to use fseek() to seek to the end of
the file, then ftell() to find out what the offset is. There's no
guarantee that the result of ftell() is meaningful for a text file
(other than as an argument to fseek()), <OT>but it should gives you a
simple byte count on Unix-like systems.</OT>

<OT>For Unix-like systems, see also the stat() function</OT>

However, knowing the length of a text file doesn't help you insert
text at the beginning of it. You'll still need to create a new file;
there's no way to shift the existing data.

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

[Michael Mair]

ritesh schrieb:

While going through this thread and writting some of my own code I
noticed this -

1. Suppose I create a text file. Write some data to it. Then close
the FILE* pointer to this file.
2. Since I have the path for the file (as char *), I can always open
the file in append mode to write more data to it.
3. What if I want to open the file in "edit" mode, and need to insert
text at the beginning of the file?

Then I'd rather open it in "r+" mode.
Note that you cannot "insert" text but that you have to read
all the file into a buffer, write the part to be inserted into
the file and then the buffer contents.
If you want to overwrite something of the same length, then
this of course is possible.

If I open using -
filePtr = fopen(filePath, "wt");

There is no 't' in standard C. You can leave it out.

then the file is truncated to zero length and I loose the previous
data.

If I open using
filePtr = fopen(filePath, "at");
then the file pointer is placed at the end of the file. If I try to
this -
rewind(filePtr);
now the filePtr moves to end of the file, since it was opened in append
mode and it allow me to move back anymore.

Nonsense. Read your C standard library reference of choice.
rewind() is in terms of positioning equivalent to
(void)fseek(stream, 0L, SEEK_SET)

I guess the only option left is to -
long int length = someFunctionToGetLengthOfFile(filePtr);
fseek(filePtr, -length, SEEK_SET);

Not at all. Read past threads on this issue.

Could someone please tell me which function would give me the length of
the text file?

C works with streams which are not only files.
There is no standard C function to do so as a stream could
have "infinite" length and/or could not be evaluated for length
as this would discard the actual "content".

Portable solutions would be best, non-portable would do
as long as they work on Linux, Unix and Solaris.

Have a look at POSIX functions and/or ask in comp.unix.programmer.
Cheers
Michael
--
E-Mail: Mine is an /at/ gmx /dot/ de address.

[av]

On Mon, 10 Jul 2006 14:26:27 -0700, "Dann Corbit" wrote:

>What happens if someone else appends data after you fseek()?

I don't think that the question has an answer.

size of file is a function of time
for example find in the time "t" the size of a file and allocate with
malloc memory == the size of file, then load that file in that memory
could be a bug if the file is more long in the time t+1

[Gordon Burditt]

>1. Suppose I create a text file. Write some data to it. Then close

>the FILE* pointer to this file.
2. Since I have the path for the file (as char *), I can always open
the file in append mode to write more data to it.
3. What if I want to open the file in "edit" mode, and need to insert
text at the beginning of the file?

There is no mode to write text to the beginning of the file *AND SHOVE
THE REST OF IT TO THE BACK OF THE FILE*. If you write a line of
50 characters, you overwrite the first 50 or so[*] bytes of the
file. If you want to prepend text to the whole file, read the file,
rewind, write the new text, then write all the old stuff.
[*] Due to differences in line endings, a line might occupy more
bytes in the file than it might appear. Consider Windows and
MS-DOS \r\n line endings.

There is no mode "wt" or "at" in standard C. Not very many systems
support on-the-fly tab expansion and compression or translation to
or from Turkish, and hopefully none of them support thermonuclear
file writes.

I think the mode you are looking for is "r+" (not "r+t"), which does
not truncate the file, but will permit fseeking and writing.

>If I open using -
filePtr = fopen(filePath, "wt");
then the file is truncated to zero length and I loose the previous
data.

If I open using
filePtr = fopen(filePath, "at");
then the file pointer is placed at the end of the file. If I try to
this -
rewind(filePtr);
now the filePtr moves to end of the file, since it was opened in append
mode and it allow me to move back anymore.

I guess the only option left is to -
long int length = someFunctionToGetLengthOfFile(filePtr);
fseek(filePtr, -length, SEEK_SET);

If you're thinking of doing that after opening the file in "a" mode,
it may not work. All writes may be forced to the end of the file.

>Could someone please tell me which function would give me the length of
the text file? Portable solutions would be best, non-portable would do
as long as they work on Linux, Unix and Solaris.

Non-standard: the return value of ftell() after fseek(filePtr, 0L,
SEEK_END) may return the current length of the file if the seek
offset is counted in bytes (rather than, say, bytes, sectors, tracks,
cylinders, and trains, packed into one integer in bitfields). This
should work on UNIX-like systems. It may get confusing on systems
with \r\n line endings.

Non-standard: Use fstat(fileno(filePtr), &statbuffer). This should
work on UNIX-like systems.

Gordon L. Burditt