ios::trunc vs unlink

[aryan]

Hi,

I would like to know which of the following would be faster

unlink(filename);
fileName.open( filename,ios:ut);

or

fileName.open( filename,ios::trunc | ios:ut);



thanks.

 

[Pascal J. Bourguignon]

Hi,

I would like to know which of the following would be faster

unlink(filename);
fileName.open( filename,ios:ut);

or

fileName.open( filename,ios::trunc | ios:ut);

Never mind the speed, they're not semantically equivalent.


Try it with filename="tata" on the file prepared as:

date > toto ; ln toto tata

The first one will keep the original file under the name toto, and
create a new file named tata, the second one will reset the file under
both names.

 

[aryan]

Which one do you think would be faster?

I am not sure. If ios::trunc does not use unlink internally, it could
be the second form.

 

[James Kanze]

Never mind the speed, they're not semantically equivalent.

Try it with filename="tata" on the file prepared as:

date > toto ; ln toto tata

The first one will keep the original file under the name toto,
and create a new file named tata, the second one will reset
the file under both names.

That particular example only applies to Unix. (And even under
Unix, who still uses hard links?) But your comment is
justified: deleting a file, then creating a new one, is not the
same thing as truncating an existing file. Under just about any
system, truncating a file will retain its old permissions;
deleting and recreating will establish new permissions. It
could have other impacts as well.

And while I'm at it, I might mention that the ios::trunc is a
no-op in the above. Anytime you open a file exclusively for
writing, it is truncated.