Austin English schrieb:
On Thu, Dec 18, 2008 at 4:22 PM, Rico Schüller kgbricola@web.de wrote:
Hi, could anyone try the attached patch for the qedit test on a windows machine? It works around bug 16548. But according to the comment in the source I think this could be a mistake. I'd like to know if it works without renaming the file on windows. On wine it works.
Cheers Rico
diff --git a/dlls/qedit/tests/mediadet.c b/dlls/qedit/tests/mediadet.c index 2b43124..558ff3a 100644 --- a/dlls/qedit/tests/mediadet.c +++ b/dlls/qedit/tests/mediadet.c @@ -68,8 +68,10 @@ static BOOL unpack_avi_file(int id, WCHAR name[MAX_PATH]) return FALSE;
DeleteFileW(name);+/*
- Renaming isn't a good way to solve this, see bug 16548. lstrcpyW(name + lstrlenW(name) - 3, avi);
+*/ fh = CreateFileW(name, GENERIC_WRITE, 0, NULL, CREATE_NEW, FILE_ATTRIBUTE_NORMAL, NULL); if (fh == INVALID_HANDLE_VALUE)
Tested on my 2k machine, works fine though. That XP machine has always been a bit buggy, so I wouldn't worry about it too much (times out on the tests a lot, even though it's got 2 GB ram/dual core CPU).
Thanks for your test.
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.
Cheers Rico