Page 1 of 1
FRIK_FILE sanity
Posted: Mon Jan 17, 2011 7:17 pm
by mh
If you've implemented FRIK_FILE you've probably noticed that opening a file in append mode is a thing of true evil. Let's bring that warm fuzzy glow of sanity to it.
First replace your PF_fopen with this version:
Code: Select all
void PF_fopen (void)
{
char *p = G_STRING(OFS_PARM0);
int fmode = G_FLOAT (OFS_PARM1);
int h = 0;
switch (fmode)
{
case 0: // read
Sys_FileOpenRead (va("%s/%s",com_gamedir, p), &h);
break;
case 1: // append -- sane version
h = Sys_FileOpenAppend (va("%s/%s", com_gamedir, p));
break;
default: // write
h = Sys_FileOpenWrite (va("%s/%s", com_gamedir, p));
break;
}
// always common now
G_FLOAT (OFS_RETURN) = (float) h;
}
Now add this to sys_win.c (or whatever, depending on your platform):
Code: Select all
int Sys_FileOpenAppend (char *path)
{
FILE *f;
int i;
i = findhandle ();
f = fopen (path, "ab");
// change this Sys_Error to something that works in your code
if (!f)
Sys_Error ("Error opening %s: %s", path, strerror (errno));
sys_handles[i] = f;
return i;
}
And finally add this to sys.h:
Code: Select all
int Sys_FileOpenAppend (char *path);
No further explanation needed, I hope.
Posted: Tue Jan 18, 2011 12:49 pm
by Team Xlink
Great tutorial.
I have a question on a possible further expansion to it:
Code: Select all
switch (fmode)
{
case 0: // read
Sys_FileOpenRead (va("%s/%s",com_gamedir, p), &h);
break;
case 1: // append -- sane version
h = Sys_FileOpenAppend (va("%s/%s", com_gamedir, p));
break;
default: // write
h = Sys_FileOpenWrite (va("%s/%s", com_gamedir, p));
break;
}
If we wanted to be able to open files from the root directory of the quake folder we should be able to use something other then com_gamedir, correct?
This would make sense in the case that you have several versions of the same mod, or different mods who all use the same file, doing this you wouldn't have to copy and past the file in each mods directory.
Would this work, are there any problems or possible errors that may appear when doing it this way?
Posted: Tue Jan 18, 2011 5:52 pm
by mh
I think it would be better to put the file into ID1 and mod FRIK_FILE to use COM_OpenFile instead. I don't like the thought of the engine being able to change files outside of a gamedir.
Posted: Tue Jan 18, 2011 6:16 pm
by Sajt
According to the DarkPlaces paradigm (of security) it shouldn't be possible, and that's a feature!
Posted: Tue Jan 18, 2011 8:38 pm
by Spike
Sajt wrote:According to the DarkPlaces paradigm (of security) it shouldn't be possible, and that's a feature!
when you support auto-downloading csqc, not even being able to read the gamedir is a very sensiblefeature.
Posted: Tue Jan 18, 2011 10:45 pm
by mh
It's bogus security anyway; any kind of client-side security is completely and utterly 100% bogus, for the simple reason that there's nothing to stop someone from downloading the code, modifying it, recompiling it, and redistributing it.
I do think it's a nice checkbox to have - "I'll play nice with you and keep my grubby little hands where they belong" - but most definitely not "security".
Posted: Wed Jan 19, 2011 6:45 am
by Sajt
I think it's reasonable to say that the user is responsible for which exe he installs. If he takes a hacked exe from an acquaintance (or non-acquaintance), instead of simply downloading the official one (with an md5 checksum and everything), you can say he has voided the warranty, and completely deserves to have his harddrive reformatted by a malicious/buggy autodownloaded progs.dat.
When the user is responsible for the exe alone, but the exe takes care of everything else, I call this security. Sure, it doesn't protect against someone hacking his computer and tampering with his files. But then, anything on his computer could be hacked. It also doesn't protect against his house being blown up by a suicide bomber. But I think that REASONABLY speaking, this can safely be called "security".