Re: side note to ppfChdir

[Pierre Phaneuf <pp@ludusdesign.com>]

Christian Reiniger wrote:

> > This is a *very* minor optimization. I think the side-effect problem
> > outweights this. I am not sure the system does starts searching directly
> > at the current working dir, see later on...
> 
> Well, ppfChdir () exists to change the current working dir, so it should
> in fact do that...

I say we can easily define this in a way that makes sense, like
"ppfChdir() changes PenguinFile current working directory", which
wouldn't do anything to the the *real* cwd.

> As an alternative we could store the path of the current dir as string
> and turn all plain paths into proper absolute ones with this before
> passing them to stdio. Which is really ugly.

*That* ugly? You have no idea of the fun related to doing a chdir() it
seems. Believe me on this: do not do this, it is Wrong.

> > Libraries should aim to be as side-effect-free as possible, shouldn't
> > they?
> 
> If the game wants to change directories it should be able to do that,
> right?

Yes. It should use chdir() then. But doing this isn't an optimization or
just a handy way to shorten file names, it has side-effects on the
system (for example, the system would be unable to unmount a CD-ROM and
core dumps gets created in all the wrong places, or not at all if your
cwd is in a CD-ROM!).

> > If you cache the open file descriptor to the pak file, you're losing
> > Unix security semantics (which you might not care much about, as many
> > other systems already lose some semantics, like NFS does with file
> > opening semantics) in the simulated file system inside the pak file.
> >
> > What I mean is that when you open a file, even with a relative path, the
> > system checks your access right to every directory starting with the
> 
> Who would decide to remove reading rights for the PakFiles in the middle
> of the game ?

That's why I mentioned you probably should just forget about this. But
you *are* changing the semantics over a real file system, and as you're
said, you wouldn't be the first to do that. :-)

> > the fact that chdir() has nasty side-effects and that it doesn't
> > actually help performance (and even if it did, it would be so marginal)
> > just tell me you should ditch that.
> 
> As described above, doing the things without chdir () is even nastier.

What? Pre-pending the "virtual cwd" inside of PFile functions (where the
user doesn't see them) is nasty? Come on!

Quadra does a chdir() to ~/.quadra, and one of the big todo is to remove
that. It is nastier than me making you slave away at PenguinFile (or at
least, is worth the slavery). ;-)

-- 
Pierre Phaneuf
http://ludusdesign.com/