On Fri, 2002-07-26 at 03:44, dsiegel at acm.org wrote:
> StandardFileStream holds a full localized pathname.
> As a consequence, if you restart an image containing
> standardFileStreams in another location, either by moving
> the image and its files, or by referencing the directory
> differently, the StandardFileStream will fail to locate
> its file.
> 
> I found this by saving an image with an open Celeste browser
> on Linux and reopening it on Windows.  Although I didn't move
> the files, on Windows I have the directory mounted via Samba,
> so the file directory prefix is '/home/dsiegel/...' on Linux, and
> 'U:/...' on Windows.
> 
> It would also have happened, though, if I simply copied the image
> and the mail database files to another directory.
> 
> It seems to me that if a StandardFileStream is opened using
> a relative pathname, it should hold a relative pathname, either
> instead of, or in addition to, the absolute pathname.
> 
> Before touching this stuff, though, I wanted the opinions
> of folks more familiar with the file layer.
> 
> Do we expect Squeak to preserve StandardFileStreams across
> image restarts?

I have hacked this stuff in the past because I wanted my WebServers to
work with relative path names, serving out of a directory located along
side the image. I agree that we need better support for relative
pathnames.

I seem to remember touching the filename code, not the stream code.

> 
> I've also heard, off and on, rumors about rewrites of the
> file and socket code in Squeak.  If any of that's actually
> happening, I don't want to duplicate work.
> 

I believe that Michael Rueger mentioned at Smalltalk Solutions 2002 that
we was doing some cleanup of the file code.

> -dms