And File::CounterFile or UUID?

Time::HiRes gives high precision time, though nanosecond resolution is unlikely.

The better idea is File::Temp. Timestamps are notoriously unreliable for your need.

Note that File::Temp does not have to "delete" the file. Is that why you were hesistating to use temp files? You can set the behavior using this method   $fh->unlink_on_destroy( 0 );

Do you want the username prefix or is it ok if you don't have that?

-SK

I mention I do not want to create temporary file because what I am dealing with is a text (one of the elements in XML).
For example say I have an XML file "Filters.xml".

<filterobj>
   <filter name="abc"/>
   <filter name="cde"/>
</filterobj>
[download]

My requirement is to read this XML and do the following.
Convert 'abc' into 'abc.processID.TimeStamp' Convert 'cde' into 'cde.ProcessID.TimeStamp'
Update the above XML file and Update another XML file which is referring to 'abc' and 'cde'.

So there is no temp file concept. I have to create unique names to use in the same file.

The problem now is I am using timestamp in seconds and there could be more than one name generated in the same second with same user provided name. So I asked for some input in creating better unique names and I asked Perl monger's comments on using milli seconds.
Thanks

The problem now is I am using timestamp in seconds and there could be more than one name generated in the same second with same user provided name.

How about using a simple incrementing number in this case? You can use sysopen to do this and avoid race conditions:

use Fcntl;

my $username = "...";
my $filename = $username . time;
my $inc = 1;

my $fh;

until (sysopen $fh, $filename.$inc, O_WRONLY|O_CREAT|O_EXCL) {
  $inc++;
}

print $fh time, "\n";
[download]

More the the point, File::Temp has a function (as Zaxo alludes to) that can generate names without creating an actual file. (The function in question is tmpnam.) Note, however, that uniqueness is not absolutely guaranteed, although it does to a very good job.

C.

"Just as unique" is imprecise. The real question is, what is the likelihood of collision in the two value spaces? Collision in pid space occurs when the pid rolls over (it's typically 15 bits) and an "old" process is still running. Collision in $^T space occurs when more than one process is started in the same clock second. For there to be a collision in the combined space, such as the OP had, you'd have to have a situation where more than 32k processes are started in the same second. That's a significantly better bet than if using either one alone.

Or is there a chance that you'd get still get duplicates?

Bingo. For truly random numbers, it's not unreasonable to get the same number 50 times in a row. Moreover, when you ask a computer for a random number, one of two things happens. Maybe it uses a pseudo-random number generator (PRNG), which has an inherent (albeit large) cycle, to get it. Or, maybe it has some way to get truly random numbers. But that falls into the first trap. To me, when someone wants uniqueness, UUID comes to mind. It's already been mentioned by another poster in this thread.

HTH,
thor

Feel the white light, the light within
Be your own disciple, fan the sparks of will
For all of us waiting, your kingdom will come

Excellent point.

So there is no temp file concept. I have to create unique names to use
+ in the same file.
[download]

Process ID + timestamp + a counter.

my $counter = 0;
sub unique_stamp {
    return join '_', $$, time, $counter++;
}
[download]

The PID makes it unique between processes. The time makes it unique in case of PID rollover. The counter makes it unique when the same process issues two stamps inside the granularity of the timer. It also makes the granularity of the time not so important.