Francois Gouget schrieb:
On Sat, 20 Dec 2008, Rico Schüller wrote: [...]
I think I've found the problem ... it is in UINT WINAPI GetTempFileNameW( LPCWSTR path, LPCWSTR prefix, UINT unique, LPWSTR buffer ) in line UINT num = GetTickCount() & 0xffff; . On fast machines GetTickCount has the same value when it is called two times in a short time. Therefore it generates the same time and as a result the same file, which isn't the case on windows. On windows it looks like there is a number increasing each run by one, something like this static UINT num; num = num++ & 0xffff; should be the solution.
To make the qedit test happy a Sleep(...) between the two calls should be enough.
In either cases, shouldn't we worry about the filename being predictable with the security issues this implies? I know this very issue has generated a lot of security issues on Unix...
The filename which is generated by GetTempFileName is always predictable. You simply have to generate 0xffff-1 files in the temp folder which match this name "prefix{xxxx}.tmp" and then GetTempFileName could only return the missing one! So I didn't see a security reason here. Security could only be given by generating the file with the correct rights. So no other app/user could change the files.
We should use the generated tmp file as it is, because there is a chance, when the qedit test deletes and generates a new one another app could have opened a file with this name already. Then the test would be skipped without a real reason.
Any suggestions how to fix the test? Should I also change the behaviour for GetTempFileName so that it matches the one from XP?
Cheers Rico