Under Windows (2K) all functions such as DeleteFile, CopyFile, MoveFile, CreateDirectory and such do return FALSE and normally set the last error to ERROR_INVALID_NAME (123) if one of the filenames passed in contains a wildcard (*?).
Wines kernel32 behaves somewhat different. Apart from returning different last errors in most cases such as:
DeleteFile: ERROR_FILE_NOT_FOUND (2) CopyFile: ERROR_BAD_PATHNAME (161) MoveFile: ERROR_FILE_NOT_FOUND (2) when source contains wildcards
which all wouldn't really be a to big issue, there is one thing which seems not right at all to me:
MoveFile with a valid existing source and a target with wildcards will create a file on disk containing wildcards in its name. This certainly can't be the intention!So according to Win2K it would be probably useful to check in all those functions for existence of wildcards in the input file paths and refuse them properly.
I took a look at the kernel32 file.c functions and saw that they usually all call DOSFS_GetFullName which is supposed to check for valid filenames and such. Problem is this function is also used in many other places and I can't get a good idea if those might need to accept wildcards in file names.
Is there anyone more familiar with the kernel32 implementation in Wine who could maybe give me some insight if an according change to DOSFS_GetFullName would be useful or rather cause possible regressions?
Otherwise the best thing to do would probably be to add explicit wildcard tests to all those file function and refuse with an according last error set. If I do not get any reactions this is probably what I will do as I'm somewhat weary to change an internal low level function such as DOSFS_GetFullName without some third party encouragement.
those functions are likely to be rewritten RSN (and DOSFS_GetFullName may even disappear) So I'd suggest rather starting by writing test cases for those functions so we could use those tests when the rewrite is going to take place
A+
those functions are likely to be rewritten RSN (and DOSFS_GetFullName may even disappear) So I'd suggest rather starting by writing test cases for those functions so we could use those tests when the rewrite is going to take place
I see the point here. Any ideas about the timeframe? Is this about calling into NTDLL instead of implementing it all in kernel32?
One question I have is how to proceed with those tests? Adding them all to the current wine tests would create serious troubles unless we fix the according issues in the already existing kernel32 functions as well, in spite of the coming rewrite.
Or do you mean different tests?
Rolf Kalbermatter
Rolf Kalbermatter wrote:
those functions are likely to be rewritten RSN (and DOSFS_GetFullName may even disappear) So I'd suggest rather starting by writing test cases for those functions so we could use those tests when the rewrite is going to take place
I see the point here. Any ideas about the timeframe?
we need a rather step by step approach here, so the complete time frame could be several months. my point in previous mail was not to stay, stop all work on these issues, but rather be aware that some changes are underway. Help is making thoses changes happen is always welcomed ;-)
Is this about calling into NTDLL instead of implementing it all in kernel32?
it depends wether the functionality exists in ntdll or not. for the move operation, we're likely to keep the existing framework: - check if source file exists - try to move it (calling ntdll.NtSetFileInformation with FileRenameInformation class) - this function will be implemented as a Unix rename - if it fails (different drive for example), then a pure copy will be implemented
One question I have is how to proceed with those tests? Adding them all to the current wine tests would create serious troubles unless we fix the according issues in the already existing kernel32 functions as well, in spite of the coming rewrite.
there's the wine_todo expression in tests which marks a test as passing on windows and failing under wine. that's the good way to do it (check that the test passes, here that a given error is reported while trying to move a file to a non correct filename)
A+
-
Eric Pouech -
Pouech Eric DMI AEI CAEN
-
Rolf Kalbermatter