[Vretsu]

-safeloading
Loads missions the old way. Typically safer, but slower.

What is the "new" way of loading missions, and how is it less safe?

[Flipside]

To be honest, I don't know, but apparently the older way was safer, but slower

[WMCoolmon]

It caches the file system in memory now, -safeloading searches the directories by trying to open the file in each applicable one.

Like walking into each room of a building to check if something is there, rather than just looking at an inventory.

[jr2]

When is the inventory created?  On game load, or when the ready room is clicked, or what?

[WMCoolmon]

Pretty sure it's game load.

[taylor]

It caches the file system in memory now, -safeloading searches the directories by trying to open the file in each applicable one.

No, the -safeloading thing was in there long before the cache change was setup, and it has nothing to do with caching at all.  All it does is make a change for Windows to use _findfirst or fopen to check if a file exists and get the size of it.  I guess it supposedly is faster than just fopen (otherwise there was zero point in adding it), but I seriously doubt it.  It makes sense when looking for a group of files, or some special attributes, but not a single file and it's size.

[WMCoolmon]

You've got it the wrong way around - safeloading enables the original fopen behavior. If caching isn't used (only for root, data, players directories, multi cache, missions, and cache) then it defaults to the findfirst behavior. The caching stuff also seems to take precedence over the command line argument.

I don't know if it'll be any faster now, but I do know that I observed a speed increase on a HDD running under PIO mode.

But yeah, that would mean that my original description is wrong. It uses the cache for all but the aforementioned directories, and then it either uses _findfirst with Windows, or fopen with the safeloading arg or Linux. At least in cf_find_file_location, which is used by most of the cf functions.

[taylor]

You probably need to take another look at the code then.  Cmdline_safeloading is used in exactly two places, doing exactly the same thing in both: using _findfirst instead of fopen.  That's all it does, with fopen being the original behaviour.  The changes were made in 2003, before I joined the project, and long before any changes were made to how the caching works.  In other words, aside from switching between fopen and _findfirst, it doesn't do anything.   Well, it does open up a loading bug, since _findfirst can access files that fopen otherwise couldn't, but that's besides the point.

[WMCoolmon]

Well...working from my local codebase (Which was updated within the last month), I see:

Code: [Select]

if ( safeloading_arg.found() ) {
Cmdline_safeloading = 1;
}

Code: [Select]

if (!Cmdline_safeloading) {
findhandle = _findfirst(longname, &findstruct);
//...
} else
#endif
{
FILE *fp = fopen(longname, "rb" );

Cmdline_safeloading is initialized to 0. And your point that _findfirst causing bugs is exactly why the flag is there in the first place, because it doesn't take into account access issues, etc that fopen would, and it's not definite proof that Freespace 2 can open the file like the code assumes it can. So if somebody has reversed what the flag does within the last month, then they've reversed the point of having it and it ought to be -unsafeloading. But as you pointed out, it's been like this for ~5 years, so I would assume that there hasn't been any serious issues with its use.

It's my code - I haven't checked on it on a long time, hence why I didn't know how it interacted with the 'new' caching stuff, but I do remember that I put the flag in in the first place to answer some of this concern, although I don't remember who raised it.