View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001484 | FSSCP | --------- | public | 2007-08-31 06:28 | 2008-10-11 12:18 |
| Reporter | Goober5000 | Assigned To | phreak | ||
| Priority | normal | Severity | major | Reproducibility | sometimes |
| Status | resolved | Resolution | fixed | ||
| Summary | 0001484: cf_get_file_list_preallocated does not filter files correctly | ||||
| Description | When investigating bug 0001483, I discovered that supposedly "deactivated" campaign files with the extension .fc21 were getting processed and lumped in with the .fc2 files. Later, when the game tried to read the .fc21 as a .fc2 (by truncating the extension and adding it back on), it generated a file-not-found error. | ||||
| Tags | No tags attached. | ||||
| related to | 0001483 | resolved | Goober5000 | Bizarre crash bug when creating a multiplayer game |
| has duplicate | 0001685 | resolved | taylor | Duplicate missions in mission list if another file extension starts with .fs2 |
|
|
Ok, no matter what I do, I can't recreate this. I tried it on Linux, OS X, Windows 2000, and Windows ME. At no time did it even try to find the other/backup files. In fact, debugging it I found that it properly ignored them altogether. Even MSDN seems to indicate that, by the way the code is setup, this situation should be impossible. So if there is a bug in there, it must be something either seriously freaky, or so blatantly obvious that it's practically invisible. So, is this still an issue for you? Maybe something that I fixed in my Xt tree without realizing it? Which OS are you running? |
|
|
Shot in the dark here but could this have been fixed when you worked on 0001182? Maybe the file was right at 34 or 35 characters in length? |
|
|
Oh dear. :sigh: Maybe this *was* fixed in the interim. It's been four months, after all. I'll see if I can reproduce the original setup and test it again this weekend. |
|
|
Or I'll test it right now. And the problem is still present. It no longer crashes because 0001483 is fixed, but it's still there. Set a breakpoint at > cf_create_default_path_string( filespec, sizeof(filespec)-1, pathtype, filter ); in cf_get_file_list_preallocated, and wait until the filter parameter is ".fc2". Then start stepping through. Even though the filespec is created correctly, the > find_handle = _findfirst( filespec, &find ); line will find the disguised file along with the others. I took Templar.fc2 and renamed it to 0Templar.fc21, and it was found. This is on Windows XP, and I suspect the problem is that XP (and possibly other versions of Windows) treats "*.extension" as "*.extension*". |
|
|
That's how I debugged it previously and it didn't do anything wrong. It should only ever check for exactly what you pass as filepsec, so if it is adding an extra * then that is definitely a Windows bug (since MSDN says that it will match only filespec, and filespec is const so the function should never modify it either). Maybe I'm just missing it or something. Are you sure that filespec itself doesn't have the extra *, or anything else other than NULL at after the .fc2? I assume that it doesn't, but it might be worth checking just in case. I'll have to confiscate an XP box in order to try and figure this out. From what I've seen there doesn't appear to be a bug on our side though. But hopefully there is a way to work around the problem at least. |
|
|
Yeah, the filespec is correct. I only tested it in a very specific scenario, so it's possible it only happens there. Run FSO without any mods installed, and start as a multiplayer pilot. Create a new multiplayer game, then wait for it to validate the missions and campaigns. Immediately after the mission validation, when the campaign validation starts (since 0Templar.fc21 was the first file in the listing) is when the bug occurs. |
|
|
Well, still can't get it to happen in either Linux or Windows builds. :( In both cases it just ignores the .fc21 and shows only the regular Templar.fc2. I have still only tried it under Wine, WinMe and Win2k. So it may actually be WinXP specific, which is something that I can't test since I don't have XP. |
|
|
Hmm. I tested it on Windows 98 and got the exact same results. :( |
|
|
Not going to work on this. |
|
|
In the Microsoft C Standard Library, the _findfirst() function is just a wrapper for the FindFirstFile() WinAPI call. I don't know if you can file a bug report with microsoft about this. Edit: Or it's just a feature of Windows. The DOS 'dir' command also exhibits this behavior. Either way just a simple file extension filter after the _findfirst call seems to do the trick. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2007-08-31 06:28 | Goober5000 | New Issue | |
| 2007-08-31 06:29 | Goober5000 | Relationship added | related to 0001483 |
| 2007-08-31 07:38 | taylor | Status | new => assigned |
| 2007-08-31 07:38 | taylor | Assigned To | => taylor |
| 2007-12-06 03:11 | taylor | Note Added: 0008740 | |
| 2007-12-06 07:46 | FUBAR-BDHR | Note Added: 0008741 | |
| 2007-12-07 08:22 | Goober5000 | Note Added: 0008742 | |
| 2007-12-07 08:48 | Goober5000 | Note Added: 0008743 | |
| 2007-12-07 09:29 | taylor | Note Added: 0008744 | |
| 2007-12-07 09:51 | Goober5000 | Note Added: 0008745 | |
| 2008-02-27 07:29 | taylor | Note Added: 0008911 | |
| 2008-03-16 01:49 | Goober5000 | Note Added: 0008982 | |
| 2008-05-04 16:05 | taylor | Relationship added | has duplicate 0001685 |
| 2008-07-17 16:33 | taylor | Note Added: 0009468 | |
| 2008-07-17 16:33 | taylor | Assigned To | taylor => |
| 2008-07-17 16:33 | taylor | Status | assigned => new |
| 2008-10-11 11:18 | phreak | Note Added: 0009932 | |
| 2008-10-11 12:03 | phreak | Note Edited: 0009932 | |
| 2008-10-11 12:04 | phreak | Status | new => assigned |
| 2008-10-11 12:04 | phreak | Assigned To | => phreak |
| 2008-10-11 12:18 | phreak | Status | assigned => resolved |
| 2008-10-11 12:18 | phreak | Resolution | open => fixed |
