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

Unique file name generation

P: n/a

Hello all,

We're presented with the problem of needing to generate a unique file name.
I've had some thoughts, but also wanted to solicit suggestions from the
group.

Any suggestions for schemes, using only *standard* C++, to do this?

Thanks,
Dave

Jul 19 '05 #1
Share this Question
Share on Google+
39 Replies


P: n/a
Dave Theese wrote:
Hello all,

We're presented with the problem of needing to generate a unique file
name. I've had some thoughts, but also wanted to solicit suggestions
from the group.

Any suggestions for schemes, using only *standard* C++, to do this?


If you want to stick to standard C++ then (IMHO) the only way to do it is
trial and error. Make a random filename (if you want to be paranoid then
within the POSIX filename limits). Try to see if it is there, if not make
one if it is there, make a new random value.

If you are ready to use platform specific code, then you might be able to
ask for your own process ID (possibly thread ID as well in MT) and use
those. I am not much familiar with POSIX, but it might provide functions
for both - and that is standard, too. And portable to many platforms.

--
WW aka Attila
Jul 19 '05 #2

P: n/a
White Wolf wrote:
Dave Theese wrote:
Hello all,

We're presented with the problem of needing to generate a unique file
name. I've had some thoughts, but also wanted to solicit suggestions
from the group.

Any suggestions for schemes, using only *standard* C++, to do this?

If you want to stick to standard C++ then (IMHO) the only way to do it is
trial and error. Make a random filename (if you want to be paranoid then
within the POSIX filename limits). Try to see if it is there, if not make
one if it is there, make a new random value.

If you are ready to use platform specific code, then you might be able to
ask for your own process ID (possibly thread ID as well in MT) and use
those. I am not much familiar with POSIX, but it might provide functions
for both - and that is standard, too. And portable to many platforms.


There is a race condition in what you describe.

The only way to guarentee that a file is not there is to use the
"exclusive" mode (O_EXCL on unix) and create the file.

I don't think there is any way to do this using std::ftream.

Jul 19 '05 #3

P: n/a
Gianni Mariani wrote:
White Wolf wrote:
Dave Theese wrote:
Hello all,

We're presented with the problem of needing to generate a unique
file name. I've had some thoughts, but also wanted to solicit
suggestions
from the group.

Any suggestions for schemes, using only *standard* C++, to do this?

If you want to stick to standard C++ then (IMHO) the only way to do
it is trial and error. Make a random filename (if you want to be
paranoid then within the POSIX filename limits). Try to see if it
is there, if not make one if it is there, make a new random value.

If you are ready to use platform specific code, then you might be
able to ask for your own process ID (possibly thread ID as well in
MT) and use those. I am not much familiar with POSIX, but it might
provide functions for both - and that is standard, too. And
portable to many platforms.


There is a race condition in what you describe.

The only way to guarentee that a file is not there is to use the
"exclusive" mode (O_EXCL on unix) and create the file.

I don't think there is any way to do this using std::ftream.


AFAIK files being created are opened exclusive on all systems by default.
Also AFAIK fstream *only* does exclusive open, since if it did not, it
should have provided locking capabilities.

--
WW aka Attila
Jul 19 '05 #4

P: n/a
White Wolf wrote:
Gianni Mariani wrote:

....

There is a race condition in what you describe.

The only way to guarentee that a file is not there is to use the
"exclusive" mode (O_EXCL on unix) and create the file.

I don't think there is any way to do this using std::ftream.

AFAIK files being created are opened exclusive on all systems by default.
Also AFAIK fstream *only* does exclusive open, since if it did not, it
should have provided locking capabilities.


The code below :

#include <fstream>

int main()
{
std::fstream x( "AFILE", std::ios_base::out );
}
Produced the following system call :

open("AFILE", O_WRONLY|O_CREAT|O_TRUNC, 0666)
There is no O_EXCL flag set. Either gcc 3.3.1 is non-compliant or
you're wrong or I mis-understood what you're saying.

Jul 19 '05 #5

P: n/a
Gianni Mariani wrote:
White Wolf wrote:
Gianni Mariani wrote:

...

There is a race condition in what you describe.

The only way to guarentee that a file is not there is to use the
"exclusive" mode (O_EXCL on unix) and create the file.

I don't think there is any way to do this using std::ftream.

AFAIK files being created are opened exclusive on all systems by
default. Also AFAIK fstream *only* does exclusive open, since if it
did not, it should have provided locking capabilities.


The code below :

#include <fstream>

int main()
{
std::fstream x( "AFILE", std::ios_base::out );
}
Produced the following system call :

open("AFILE", O_WRONLY|O_CREAT|O_TRUNC, 0666)
There is no O_EXCL flag set. Either gcc 3.3.1 is non-compliant or
you're wrong or I mis-understood what you're saying.


One of those. :-) Last time I was checking those things (I cannot recall on
which OSes I really did) when you have _created_ a file (it was not there)
there was no way to open it not-exclusively. You had to close and reopen
it. Probably that was too long time ago and it is different nowadays. But
it made sense to me.

IMHO since fstream provides no standard way to get the file descriptor and
no interface for file locking, it strikes me as a design error to open files
for shared access inside it.

--
WW aka Attila
Jul 19 '05 #6

P: n/a
Dave Theese wrote:
Hello all,

We're presented with the problem of needing to generate a unique file name.
I've had some thoughts, but also wanted to solicit suggestions from the
group.

Any suggestions for schemes, using only *standard* C++, to do this?

Thanks,
Dave


std::tmpnam() is the closest thing I know of.

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.

Jul 19 '05 #7

P: n/a
Kevin Goodsell wrote:
Dave Theese wrote:
Hello all,

We're presented with the problem of needing to generate a unique
file name. I've had some thoughts, but also wanted to solicit
suggestions from the group.

Any suggestions for schemes, using only *standard* C++, to do this?


std::tmpnam() is the closest thing I know of.


Ahh! That one I did not know... Back to the books...

--
WW aka Attila
Jul 19 '05 #8

P: n/a
White Wolf wrote:
Kevin Goodsell wrote:
Dave Theese wrote:
Hello all,

We're presented with the problem of needing to generate a unique
file name. I've had some thoughts, but also wanted to solicit
suggestions from the group.

Any suggestions for schemes, using only *standard* C++, to do this?


std::tmpnam() is the closest thing I know of.


Ahh! That one I did not know... Back to the books...


In addition to this I also see tmpfile() to open it and make it sure that it
is cleaned up upon process termination.

However for tmpnam I see no quarantee in the standard that it returns a name
which attempts to be unique in the system. It only says that it will not
return the same name twice and will not return the name of an existing file.

--
WW aka Attila
Jul 19 '05 #9

P: n/a
White Wolf wrote:

In addition to this I also see tmpfile() to open it and make it sure that it
is cleaned up upon process termination.
Unfortunately as a FILE *, not fstream.

However for tmpnam I see no quarantee in the standard that it returns a name
which attempts to be unique in the system. It only says that it will not
return the same name twice and will not return the name of an existing file.


If a file with the name doesn't exist, doesn't that imply the name is
unique?

One possible problem with tmpnam is that the file could suddenly spring
into existence after you retrieve the name, before you can create it
yourself.

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.

Jul 19 '05 #10

P: n/a
Kevin Goodsell wrote:
White Wolf wrote:

In addition to this I also see tmpfile() to open it and make it sure
that it is cleaned up upon process termination.
Unfortunately as a FILE *, not fstream.

However for tmpnam I see no quarantee in the standard that it
returns a name which attempts to be unique in the system. It only
says that it will not return the same name twice and will not return
the name of an existing file.


If a file with the name doesn't exist, doesn't that imply the name is
unique?


Of course not. It implies that *at the time* when the implementation has
checked it, it was not there. But at the time your code tries to create it,
it might be there. There can be several processes running on a computer.
And several comupters accessing the same disk.
One possible problem with tmpnam is that the file could suddenly
spring
into existence after you retrieve the name, before you can create it
yourself.


Yes. And that is what it means "not unique in the system". There is no
bulletin board where all processes on all the computers accessing this
storage area would place a post-it: I am using this name, do not take it!

--
WW aka Attila
Jul 19 '05 #11

P: n/a
On Sun, 14 Sep 2003 03:06:19 +0300, "White Wolf" <wo***@freemail.hu>
wrote in comp.lang.c++:
Kevin Goodsell wrote:
White Wolf wrote:

In addition to this I also see tmpfile() to open it and make it sure
that it is cleaned up upon process termination.


Unfortunately as a FILE *, not fstream.

However for tmpnam I see no quarantee in the standard that it
returns a name which attempts to be unique in the system. It only
says that it will not return the same name twice and will not return
the name of an existing file.


If a file with the name doesn't exist, doesn't that imply the name is
unique?


Of course not. It implies that *at the time* when the implementation has
checked it, it was not there. But at the time your code tries to create it,
it might be there. There can be several processes running on a computer.
And several comupters accessing the same disk.
One possible problem with tmpnam is that the file could suddenly
spring
into existence after you retrieve the name, before you can create it
yourself.


Yes. And that is what it means "not unique in the system". There is no
bulletin board where all processes on all the computers accessing this
storage area would place a post-it: I am using this name, do not take it!


Since neither C++, nor C from which it inherits the tmpnam() library
function, define or specifically support multiple processes, it is
impossible for a library function to provide the guarantees that the
OP wants.

File systems belong to operating systems, not to C++ or any other
language. The best thing to do in a case like this is to use a
platform specific extension, if one is available.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++ ftp://snurse-l.org/pub/acllc-c++/faq
Jul 19 '05 #12

P: n/a
Jack Klein wrote:
[SNIP]
Since neither C++, nor C from which it inherits the tmpnam() library
function, define or specifically support multiple processes, it is
impossible for a library function to provide the guarantees that the
OP wants.
:-)
File systems belong to operating systems, not to C++ or any other
language. The best thing to do in a case like this is to use a
platform specific extension, if one is available.


So back to square one. Trial and error. tmpnam might give back a unique
name, but it is only unique at that instance - when the program has checked
the files existence. So basically we are where we were in my first post,
except that we have a standard way to generate (limited number of!) those
filenames.

--
WW aka Attila
Jul 19 '05 #13

P: n/a
> std::tmpnam() is the closest thing I know of.

I think it is deprecated and replaced by mkstemp()
Like this:

#include <cstdlib>

int main() {
char _tmpFileName[] = "MYAPPXXXXXX";
mkstemp(_tmpFileName);

_tmpfile.open(_tmpFileName, ios::out | ios::in | ios::trunc);
}
--
Jan Rendek
INRIA Lorraine
r e n d e k @ l o r i a . f r

Jul 19 '05 #14

P: n/a
Jan Rendek wrote:
std::tmpnam() is the closest thing I know of.


I think it is deprecated and replaced by mkstemp()


No it is not. Neither in C99 nor in C++98 standards.

mkstemp is not a standard function. Neither in C99 nor in C++98 standards.

Please refrain from posting wild guesses.

--
Attila aka WW
Jul 19 '05 #15

P: n/a
"Attila Feher" <at**********@lmf.ericsson.se> writes:
Jan Rendek wrote:
std::tmpnam() is the closest thing I know of.


I think it is deprecated and replaced by mkstemp()


No it is not. Neither in C99 nor in C++98 standards.

mkstemp is not a standard function. Neither in C99 nor in C++98 standards.


I guess Jan got confused by the (Linux?) manpage for tmpnam and/or the gcc
compiler; both state that tmpnam() is deprecated and mkstemp() should be used
instead.
Of course, given that tmpnam() is standard and mkstemp() is not, this
advice is quite unfortunate.

kind regards
frank

--
Frank Schmitt
4SC AG phone: +49 89 700763-0
e-mail: frank DOT schmitt AT 4sc DOT com
Jul 19 '05 #16

P: n/a
Frank Schmitt wrote:
"Attila Feher" <at**********@lmf.ericsson.se> writes:
Jan Rendek wrote:
std::tmpnam() is the closest thing I know of.

I think it is deprecated and replaced by mkstemp()


No it is not. Neither in C99 nor in C++98 standards.

mkstemp is not a standard function. Neither in C99 nor in C++98
standards.


I guess Jan got confused by the (Linux?) manpage for tmpnam and/or
the gcc compiler; both state that tmpnam() is deprecated and
mkstemp() should be used instead.
Of course, given that tmpnam() is standard and mkstemp() is not, this
advice is quite unfortunate.


Hm. Then I guess if some of you know how to report bugs regarding those
manpages it would be a good idea to report this. I mean they can of course
say in the manpage that in our environment we have mkstemp what is far
superior to the language standard tmpnam function and we suggest you use
ours... but is I understand you the current wording is very misleading.

--
Attila aka WW
Jul 19 '05 #17

P: n/a
> mkstemp is not a standard function. Neither in C99 nor in C++98 standards.

My mistake. I was ideed mislead by the linux man pages.
--
Jan Rendek
INRIA Lorraine
r e n d e k @ l o r i a . f r

Jul 19 '05 #18

P: n/a
Jan Rendek wrote:
mkstemp is not a standard function. Neither in C99 nor in C++98
standards.


My mistake. I was ideed mislead by the linux man pages.


First time in my life that Linux is actually blamed not Mircosoft! Let's
remember the date. :-)

--
Attila aka WW
Jul 19 '05 #19

P: n/a
Attila Feher wrote:
Frank Schmitt wrote:
"Attila Feher" <at**********@lmf.ericsson.se> writes:

Jan Rendek wrote:

>std::tmpnam() is the closest thing I know of.

I think it is deprecated and replaced by mkstemp()

No it is not. Neither in C99 nor in C++98 standards.

mkstemp is not a standard function. Neither in C99 nor in C++98
standards.


I guess Jan got confused by the (Linux?) manpage for tmpnam and/or
the gcc compiler; both state that tmpnam() is deprecated and
mkstemp() should be used instead.
Of course, given that tmpnam() is standard and mkstemp() is not, this
advice is quite unfortunate.

Hm. Then I guess if some of you know how to report bugs regarding those
manpages it would be a good idea to report this. I mean they can of course
say in the manpage that in our environment we have mkstemp what is far
superior to the language standard tmpnam function and we suggest you use
ours... but is I understand you the current wording is very misleading.


I think there is a security vulnerability with tmpnam.

Standard or not, it is highly reccomended NOT to add security
vulnerabilities. I'd have to agree with the GNU guys on this - (if my
sentence above is true).

Jul 19 '05 #20

P: n/a
Attila Feher wrote:
Jan Rendek wrote:
mkstemp is not a standard function. Neither in C99 nor in C++98
standards.


My mistake. I was ideed mislead by the linux man pages.

First time in my life that Linux is actually blamed not Mircosoft! Let's
remember the date. :-)


Slow down now. Let's not rush to conclusions. :^)

Jul 19 '05 #21

P: n/a
Gianni Mariani wrote:
[SNIP]
I think there is a security vulnerability with tmpnam.

Standard or not, it is highly reccomended NOT to add security
vulnerabilities. I'd have to agree with the GNU guys on this - (if my
sentence above is true).


Sorry to say but this is spreading FUD. If you do not know that there are
any security problems with a function do not say so. If you do know, please
post its description so that everyone can examine and benefit from the
facts.

--
Attila aka WW
Jul 19 '05 #22

P: n/a
Attila Feher wrote:
Gianni Mariani wrote:
[SNIP]
I think there is a security vulnerability with tmpnam.

Standard or not, it is highly reccomended NOT to add security
vulnerabilities. I'd have to agree with the GNU guys on this - (if my
sentence above is true).

Sorry to say but this is spreading FUD.


If you know better, please elaborate.

If you do not know that there are any security problems with a function do not say so.
It takes a few seconds to see.

If you do know, please post its description so that everyone can examine and benefit from the
facts.


http://www.google.com/search?hl=en&i...=Google+Search
Google is your friend.
Jul 19 '05 #23

P: n/a
Jan Rendek wrote:
mkstemp is not a standard function. Neither in C99 nor in C++98 standards.


My mistake. I was ideed mislead by the linux man pages.

Well, the man pages aren't designed to reflect ISO Standard C++. They
document available functionality for the programming environment. This
will be a mixture of ISO C++, ISO C, POSIX, other standards like X11,
and implementation specific stuff.

Their advice is likely quite correct for LINUX programming, not for ISO
C++ programming.


Brian Rodenborn
Jul 19 '05 #24

P: n/a
Default User wrote:
Jan Rendek wrote:
mkstemp is not a standard function. Neither in C99 nor in C++98
standards.


Their advice is likely quite correct for LINUX programming, not for
ISO C++ programming.


Why? Is that mkstemp a POSIX function?

--
WW aka Attila
Jul 19 '05 #25

P: n/a

"White Wolf" <wo***@freemail.hu> wrote in message news:bk**********@phys-news1.kolumbus.fi...
Why? Is that mkstemp a POSIX function?


Yes.
Jul 19 '05 #26

P: n/a
Ron Natalie wrote:
"White Wolf" <wo***@freemail.hu> wrote in message
news:bk**********@phys-news1.kolumbus.fi...
Why? Is that mkstemp a POSIX function?


Yes.


OK then! I myself say many times to use xnprintf and strncpy and so forth
and they are not standard (in C++). BTW it would still be nice if they did
mention compatibility/portability and say that mkstemp is not part of the C
or C++ language.

--
WW aka Attila
Jul 19 '05 #27

P: n/a

"White Wolf" <wo***@freemail.hu> wrote in message news:bk**********@phys-news1.kolumbus.fi...
Ron Natalie wrote:
"White Wolf" <wo***@freemail.hu> wrote in message
news:bk**********@phys-news1.kolumbus.fi...
Why? Is that mkstemp a POSIX function?
Yes.


OK then! I myself say many times to use xnprintf and strncpy and so forth
and they are not standard (in C++).


strncpy is standard C++. See the <cstring> header.
BTW it would still be nice if they did
mention compatibility/portability and say that mkstemp is not part of the C
or C++ language.


The LINUX man pages do tell you. There is a line towards the end of each
manual page that tells you what stanards (SVID, BSD, C, POSIX...) the
function is derived from.
Jul 19 '05 #28

P: n/a
Ron Natalie wrote:
OK then! I myself say many times to use xnprintf and strncpy and so
forth
and they are not standard (in C++).


strncpy is standard C++. See the <cstring> header.


Hm. I have to practice my text-search skills. In humiliating myself I am a
master. How could I have searched for this name and not found it? I might
have typed it by mistake as strncopy or something. BTW I have done this
search at least 3 times during the last 2 years. And I am only 34. How
stupid will I get later? At least I have a Guinness record waiting down the
road. :-)

--
WW aka Attila
Jul 19 '05 #29

P: n/a
White Wolf wrote:

Default User wrote:
Jan Rendek wrote:

mkstemp is not a standard function. Neither in C99 nor in C++98
standards.


Their advice is likely quite correct for LINUX programming, not for
ISO C++ programming.


Why? Is that mkstemp a POSIX function?

Yes, but even if it was a platform-specific function, then the man pages
would be correct FOR THE IMPLEMENTATION.

Don't use man pages in place of the C++ standard. Even the description
of standard constructs may be described by man pages in an
implementation-specific manner (for instance, errno values that aren't
guaranteed to be set in ISO Standard C or C++).

Brian Rodenborn
Jul 19 '05 #30

P: n/a
Default User wrote:
Don't use man pages in place of the C++ standard.


When did I say I do?

--
WW aka Attila
Jul 19 '05 #31

P: n/a
White Wolf wrote:

Default User wrote:
Don't use man pages in place of the C++ standard.


When did I say I do?

When did I say you said you did?
You were the one who started bleating about standards and man pages. I'm
reiterating, in case you didn't get the message, that the man pages
ain't the standard.


Brian Rodenborn
Jul 19 '05 #32

P: n/a
Default User wrote:
White Wolf wrote:

Default User wrote:
Don't use man pages in place of the C++ standard.
When did I say I do?


When did I say you said you did?


You have answered my post.
You were the one who started bleating about standards and man pages.
I'm reiterating, in case you didn't get the message, that the man
pages ain't the standard.


Yes. And I have never ever stated that they are. What I have said is that
I find it wrong for a man page to dedicate a function deprecated (while it
is not in its corresponding standard).

BTW do not get personal with me. Remarks like your bleating show only your
cluelessness and arrogance. They have no argumentative or technical (or any
kind of positive) value whatsoever.

--
WW aka Attila
Jul 19 '05 #33

P: n/a
White Wolf wrote:
Yes. And I have never ever stated that they are. What I have said is that
I find it wrong for a man page to dedicate a function deprecated (while it
is not in its corresponding standard).
You still don't get it.
BTW do not get personal with me.
It's been my experience that people who complain about people getting
personal never seem to mind do so when it suits their purpose.
Remarks like your bleating show only your cluelessness and arrogance.


Like so.


Brian Rodenborn
Jul 19 '05 #34

P: n/a
Default User wrote:
White Wolf wrote:
Yes. And I have never ever stated that they are. What I have said
is that I find it wrong for a man page to dedicate a function
deprecated (while it is not in its corresponding standard).


You still don't get it.


I have got it my friend. But it seems you love to argue. You have stated I
do not know the difference. I have asked you for proof - if I have ever
said anything like that. You started to get personal but gave no proof. I
have answered and you have got even more personal.

Well, I am not going to try to find out why are you doing this, but I also
suggest that you don't try to find out what I think or know either. And
especially not state it in public as if I had anything to do with it. Since
it seems your understanding of my words is limited, I suggest you rather ask
if something is unclear than go into some sort of ranting against a
statement I have never made.
BTW do not get personal with me.


It's been my experience that people who complain about people getting
personal never seem to mind do so when it suits their purpose.


Yeah. Is it so? Maybe it is time for you to start respecting people, not
gettinf personal and they won't get personal with you.
Remarks like your bleating show only your cluelessness and arrogance.


Like so.


Yes, like so. This was a general remark. ("you" as "one" is a general
subject, at least that is what I have learnt in school).

--
WW aka Attila
Jul 19 '05 #35

P: n/a
White Wolf wrote:
Default User wrote:
White Wolf wrote:


.... love fest snipped

Please fellas, go get married.

We don't really need any of this here.

Regards
G

Jul 19 '05 #36

P: n/a
Gianni Mariani wrote:
[SNIP]
I think there is a security vulnerability with tmpnam.

Standard or not, it is highly reccomended NOT to add security
vulnerabilities. I'd have to agree with the GNU guys on this - (if
my sentence above is true).

Sorry to say but this is spreading FUD.


If you know better, please elaborate.


You claim there is a security risk. It was not me who have accused a
standard library function to be a security risk. It is not my job to prove
anything. It is yours.
If you do not know that there are
any security problems with a function do not say so.
It takes a few seconds to see.


OK. Then take that few seconds to see it and share it with us. So far you
are spreading FUD with zero support from facts.
Google is your friend.


Yes. However it is not my job to support you argument. It is yours.

--
Attila aka WW
Jul 19 '05 #37

P: n/a
Attila Feher wrote:
....
Google is your friend.

Yes. However it is not my job to support you argument. It is yours.


If you have the impression I wish to *argue* you are mistaken.

I'm not interested in taking this further.

Jul 19 '05 #38

P: n/a
Gianni Mariani wrote:
Attila Feher wrote:
Yes. However it is not my job to support you argument. It is yours.


If you have the impression I wish to *argue* you are mistaken.

I'm not interested in taking this further.


No proof, bail out. That is also a way to do it.

--
Attila aka WW
Jul 19 '05 #39

P: n/a
Gianni Mariani wrote:

White Wolf wrote:
Default User wrote:
White Wolf wrote:


... love fest snipped

Yeah, really. WW has his panties in a wad, and has decided to go into
super, "I'm playing language lawyer and not going to listen to anything
you say except to pick small things that I can use to make it seem like
you are an ignorant fool blah blah."

Well, I don't need to play that game, so I'll do the best thing can,
ignore his ravings. He can stalk my posts all he wants, won't make a bit
of difference to me.

Brian Rodenborn
Jul 19 '05 #40

This discussion thread is closed

Replies have been disabled for this discussion.