2019-01-22 08:34 EST

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0001484FSSCP---------public2008-10-11 08:18
Assigned Tophreak 
Product Version 
Target VersionFixed in Version 
Summary0001484: cf_get_file_list_preallocated does not filter files correctly
DescriptionWhen 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.
TagsNo tags attached.
Attached Files

related to 0001483resolvedGoober5000 Bizarre crash bug when creating a multiplayer game 
has duplicate 0001685resolvedtaylor Duplicate missions in mission list if another file extension starts with .fs2 



taylor (administrator)

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?


FUBAR-BDHR (developer)

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?


Goober5000 (administrator)

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.


Goober5000 (administrator)

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*".


taylor (administrator)

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.


Goober5000 (administrator)

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.


taylor (administrator)

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.


Goober5000 (administrator)

Hmm. I tested it on Windows 98 and got the exact same results. :(


taylor (administrator)

Not going to work on this.


phreak (developer)

Last edited: 2008-10-11 08:03

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.


-Issue History
Date Modified Username Field Change
2007-08-31 02:28 Goober5000 New Issue
2007-08-31 02:29 Goober5000 Relationship added related to 0001483
2007-08-31 03:38 taylor Status new => assigned
2007-08-31 03:38 taylor Assigned To => taylor
2007-12-05 22:11 taylor Note Added: 0008740
2007-12-06 02:46 FUBAR-BDHR Note Added: 0008741
2007-12-07 03:22 Goober5000 Note Added: 0008742
2007-12-07 03:48 Goober5000 Note Added: 0008743
2007-12-07 04:29 taylor Note Added: 0008744
2007-12-07 04:51 Goober5000 Note Added: 0008745
2008-02-27 02:29 taylor Note Added: 0008911
2008-03-15 21:49 Goober5000 Note Added: 0008982
2008-05-04 12:05 taylor Relationship added has duplicate 0001685
2008-07-17 12:33 taylor Note Added: 0009468
2008-07-17 12:33 taylor Assigned To taylor =>
2008-07-17 12:33 taylor Status assigned => new
2008-10-11 07:18 phreak Note Added: 0009932
2008-10-11 08:03 phreak Note Edited: 0009932
2008-10-11 08:04 phreak Status new => assigned
2008-10-11 08:04 phreak Assigned To => phreak
2008-10-11 08:18 phreak Status assigned => resolved
2008-10-11 08:18 phreak Resolution open => fixed
+Issue History