GetTempFileName weird behaviour

[Molochnik]

I wouldn't say its a bug but cant say its a feature either.
GetTempFileName returns filenames sequentially based on files existence. Its behaviour differs from both Windows GetTempFileName version and Delphi realization on all OSs which return random values.
What if I need two temp files without creating them? Or two threads decide to get a temp filename simultaneously?

[KodeZwerg]

In one of my projects I do use a custom method.
I stripped it down to the part about having a random filename generated without further checks:

Code: Pascal  [Select][+][-]

1. function CreateTmpFilename(out AFilename: AnsiString): Boolean;
2. var
3.   GUID: TGUID;
4.   s: AnsiString;
5. begin
6.   Result := False;
7.   if CreateGUID(GUID) = 0 then
8.     begin
9.       s := GuiDToString(Guid);
10.       AFilename := Copy(s, 2, Pred(Length(s)) - 1);
11.       AFilename := AFilename + '_' + IntToStr(GetTickCount64) + '.tmp';
12.       UniqueString(AFilename);
13.       Result := True;
14. //      CreateFile(
15.     end;
16. end;

In my usage the method does not stop there it calls CreateFile() to do 2 things at once, it tells me if filename is already present (what I doubt but chance is given) and second it physical create the file, in co-work with EnterCriticalSection/ExitCriticalSection it returns me the the filehandle instead of a string.

[Thaddy]

What if I need two temp files without creating them? Or two threads decide to get a temp filename simultaneously?

Where is your logic? Did you not realize that the tempfile name has to be checked for existance before creating it?
BTW the GUID approach is appropiate in all cases, but still the check needs to be made to be absolutely sure.

[Molochnik]

Where is your logic?

Logic is very simple, it is how it is been done long ago in Windows and Delphi and I think people rely on that

[Molochnik]

BTW the GUID approach is appropiate in all cases, but still the check needs to be made to be absolutely sure.

Checking the file name and actually using it may differ in time.

[Molochnik]

KodeZwerg
yes I know the same approach is used in Delphi, of course when I already know I can easily make a workaround, but still

[Molochnik]

Thaddy
And I can easily create a working example where checking the file existence is absolute nonsense: when you pass your temp file name as output to some conversion utility like for example lame

[Thaddy]

Thaddy
And I can easily create a working example where checking the file existence is absolute nonsense: when you pass your temp file name as output to some conversion utility like for example lame

does not make sense either way, before you create a temp file you first need to check if your generated temp file name already exists. period.

[KodeZwerg]

What if I need two temp files without creating them? Or two threads decide to get a temp filename simultaneously?

Where is your logic? Did you not realize that the tempfile name has to be checked for existance before creating it?
BTW the GUID approach is appropiate in all cases, but still the check needs to be made to be absolutely sure.

I agree and would like to add that at the point of generating a random filename, "checking" for existance and rely to that result for the next steps is in my opinion already too late.
I am unsure but think CreateFile() is Windows Api specific so I do not know how to crossplatform... maybe with a TStream as replacement to work with?
My own app uses Windows Api to create me a filehandle what I can use (it loops itself if filename is given and expect as input an existing filepath), multithreaded.

[Molochnik]

it tells me if filename is already present (what I doubt but chance is given)

it's paranoid, but when writing a server you should be a paranoid
PS found TPath.GetGUIDFileName function which suites me perfect