Re: side note to ppfChdir

[Pierre Phaneuf <pp@ludusdesign.com>]

Christian Reiniger wrote:

> > Having to do a real chdir() is a bad idea IMHO. The problem is that it
> > changes the general behavior of the program, for example, if it core
> > dumps, the dump will not be in the expected place. Example:
> 
> The problem is that PFile can be used to read perfectly normal files (just
> like stdio). Furthermore the user doesn't have to specify whether the file
> he wants to open is a perfectly normal file or some file in a PakFile or
> something else. That means ppfChdir () has to ensure that both the
> "normal" current working dir (as set by chdir ()) and the PFile VFS current
> working dir point to the same logical directory.

You could virtualize the cwd by keeping it in a variable and pre-pending
it if the file name doesn't begin with a directory separator. If the
user want to *really* change the cwd, he simply has to use chdir(). You
*could* some state information in addition to the simple path string to
potentially accelerate some pak file functions, but the stdio calls
would get fully qualified paths.

> If you don't understand that, don't worry. It *is* difficult. I'm writing a
> doc section explaining this.

Don't worry about me, will ya? :-) By day, I'm a system analyst on
weather modeling supercomputers, worrying about clustering-related
multithreaded kernel deadlock problems in high performance applications
and things like that. Layered storage subsystems, I also meddle with.

> Until that is ready, please trust me that chdir () *should* be called ;)

I don't trust you a second, I guess that's why I like the open source
development model. ;-)

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