Hi Michael,
there are several thinks you could check.
1. Could you get a wrong order on winxp/vista/7 by using the default
installation on a local FAT32 partition? Or does the order by accident
match? If this doesn't reproduce the issue, you may also try the ext2fs
driver for windows, as this seems to be allowed too. Does the default
installation on a network drive with e.g. ext3 work correctly? I
couldn't find anything, that the game has to be on NTFS, so this might
be a valid bug to report to the support for the game. The solution might
be, that they fix the issue (then we are lucky) or they will only allow
NTFS (FAT32) partitions.
2. While we don't know if this will be fixed in 1. in one way or the
other, we may try the following. What happens if you use wine and a NTFS
or FAT32 partition where the game is on? Does the order match? Maybe the
game requires NTFS (and/or FAT32) as file system? Does the NTFS (FAT32)
driver handle the order correctly? Maybe it's a bug in the NTFS (FAT32)
driver or i might just work by accident?
3. What's the network file system type in your test? Does it work if it
is a NTFS (FAT32) file system?
I think, changing the Find* functions is bad, as there will most likely
an app which depends on the order of the file creation date on FAT32
partitions...
It may be worth a try to report it as a bug to the game support, but try
to be as close to the system requirements as possible.
Cheers
Rico
On 24.07.2013 04:17, Michael Casadevall wrote:
Hey all,
I've been working on trying to get Sid Meier's Civilization V (Civ5) up
to a point where it works relatively flawlessly on WINE. The largest
issue is that installing the latest expansion pack has completely hosed
the game under WINE unless some rather ugly workarounds have been taken.
Specifically, the main issue is that Civ5 loads its data files in the
order returned by Find{First,Next}File(), and breaks spectacularly if
that order is disrupted. I documented my findings here:
http://bugs.winehq.org/show_bug.cgi?id=34122
As I sat to look at a possible patch, I'm not sure what I can actually
do. Its clearly stated on the MSDN page that the order returned is
dependent on the underlying filesystem, and Googling suggests that while
NTFS seems to always return in a roughly alphabetical order, FAT32 will
return by creation date, and with network drives all bets are off. I was
even able to reproduce similar bugs in Civ5 by launching it from a
network drive (which I had already tested in advance to make sure it
returned an odd file order). FindFirstFile essentially calls down to
NtQueryDirectoryFile, which in turn either calls a system specific
syscall or readdir to get a list of files in a directory.
My first thought is to extend the underlying read_directory_* functions
in ntdll/directory.c so that they return an alphabetized list
(essentially taking the results from getdents/getdirentries/readdir,
sort them, then returning in the sort order whichever entry is next in
line). This would produce a behavior similar (but not identical) to what
is seen when operating under an NTFS filesystem.
This approach seems wrong to me, and is further compounded by the fact
this is a bug in an application, and not in WINE specifically; Under the
correct circumstances, Windows will return a "non-sorted" list of files
and in those cases Civilization V breaks. The flipside is that in the
most common case, it works correctly, and furthermore, given how easy it
is to assume that Find*File does return a sorted list, I won't be
surprised if this issue has cropped up elsewhere (figuring out the
underlying cause was exceedingly annoying). Any insight in to what the
most correct course of action would be most appreciated
I'm perfectly willing to put the legwork in fixing this bug, but I want
to make sure I'm fixing it in a way that will be accepted :-).
Regards,
Michael
