[physfs] windows eccentricities...

[Miles Vignol]

> Technically, you have everything you need for this, but you have to make a 
> few assumptions:
>
> 1) You need to provide the GUI, either by wiring it up to the OS's file 
> picker if possible, or making your own dialog. Obviously, UI work is 
> beyond the scope of physfs itself.

right.  that's why i was considering my options.  my app is written for SDL 
(started out with glut, then went with cpw which ended up being not very 
"cp" before landing with sdl).  i've written a bunch of gui stuff, but 
getting to the file-selector i petered out.  i was hoping native file-boxes 
would be easy calls to make, but it appears to not be the case.  i've looked 
at wx widgets but i don't feel like re-writing my whole app in c++ and 
widgets is WAY more api than i need, tho it does sound nice.  physfs seems 
like it's pretty much what people who use sdl use for cross-platform file 
access, so that's how i ended up with it.  i started writing a selector box, 
then put the project down for a (long) while.  getting back to it, i 
remember why this part sorta killed the momentum.  bleah.

> 2) If you want a general system-wide dialog, you'd have to add just the 
> root of the file system to the search path, or use the mount points and 
> put it in a directory that doesn't overlap with the rest of your search 
> path (unless you want it to do interpolation, but that's probably not what 
> what you want).

which brings me to another thing i've been thinking about.  can you push/pop 
search paths?  it'd be nice to push "/" do my business then pop back to what 
it was before.  i could handle this internally, but was just curious if 
there was a way to deal with already inside physfs...

> 3) If you're on Windows or OS/2, you'd have to write some native glue code 
> to enumerate each existing drive letter and use the mount point API to 
> make sure they don't overlap in the physicsfs file tree. You can steal 
> this code, if you need it, from platform/win32.c and platform/os2.c, since 
> we needed this internally to find the CD drives anyhow.

i started using something, but i dunno where i got it from.  it was kinda 
junky.  i'll look into those.  os/2 isn't an issue for me... i'm only 
targetting linux, windows and os x.  the fringe dwellers will just have to 
do without!  not sure i follow the mount point caveat, tho.  can you explain 
more?

> 4) ':' isn't valid in physfs filenames, either, so this would end up 
> looking like /c/windows/system32 or /nativefiles/cdrive/windows/system32 
> or whatever...Unix obviously won't have this issue, and techically MacOS 
> can get around it (either just start at the root of the file tree, or 
> start in the /Volumes folder if you want the various drives to be the top 
> of the tree). Cygwin uses /cygdrive/c/windows/system32 for making Windows 
> drives fit a Unix filesystem schema, and "/" is actually somewhere in the 
> middle of the tree (C:\cygwin, usually), for comparison.

yeah, ms's services for unix uses some other mapping like "/dev/fs/c" or 
something.  neither is ideal in that they imply a different "depth" in the 
file system, but maybe it's not a huge issue.  perhaps i can setup a 
"project path" using the mounting api and try to keep everything relative to 
that path.  ideally, part of cross platform would mean that the program can 
run using the same data/inputs on each platform it runs on.  having to 
"refocus" a path or two when switching platforms isn't a deal breaker in 
this regard.

> In terms of file i/o, if the interpolated tree isn't an issue, you'll have 
> everything you need: file enumeration and isDir, isFile, isSymLink 
> support. I'd say you'd have to use the mount points API in the Subversion 
> repository to make this possible in any reasonable way, though.

what do you mean by interpolated tree?

> Whether this makes the effort worth it or not depends on your needs and 
> your free time.  :)
>
> If you take a stab at it, report back on how it goes for you.

yeah, i will.  and i'll probably have a ton of questions, too!


-miles vignol
fathom entertainment