Re: FileGlobalData::SetCWD()

[Christian Reiniger <warewolf@mayn.de>]

pcburns@zip.com.au wrote:
>FileGlobalData::SetCWD() seems to have problems. It calls GetCWDPlain()
>which returns the path as a char* using a PFile virtual path.
>
>eg it returns c:/some/path as c/some/path
>
>Now can you tell me if c/some/path is absolute or not?

No. Correct. I now fixed this by letting GetCWDPlain () return a URLInfo
object (which is better than passing around strings anyway, as all internal
processing is done on URLInfo objects, so this might even save a few
conversions)

>Why does it get the current directory and then set the
>current directory to the current directory? The answer is that SetCWD doesn't 
>just set the current working directory. It has other functionality that 
>initialises the data in FileGlobalData. This functionality should be moved to a 

Nope. The thing is that PFile has *two* current working dirs - one for the
native filesystem and one for the (internal) virtual one. The reason is
that you can ppfChdir to a directory in the virtual FS (e.g. a subdir in
some PakArchive) that doesn't exist in the native one.
The CreateSubDir () function ensures that, if a nes CWD is set, a proper
directory in the virtual FS exists. (Example: you change to
/usr/src/foobar/, which doesn't exist in the VFS yet - but there's no
reason why it shouldn't be there, especially as the user now wants to work
in it. So it's quickly created).

The SetCWD (GetCWD ()) thing is because this internal CWD has to be
properly set at startup time. So we set it to the "real" CWD.

I added some comments explaining that.


>After looking at the Unix.cpp version of GetCWD it seems that there is a 
>problem with the win32.cpp version. I think that GetCWDPlain should return a 

Actually also the Unix version only worked correctly by luck, because PFile
URLs and Un*x native paths don't need any conversion between each other in
this case.

Anyway, it should be fixed now.


	Christian
-- 

Drive C: not found: (A)bort (R)etry (P)anic