Colin Putney wrote:
> I expect that to improve, but in the meantime, it's possible to use 
> StandardFileStream with FSDiskFilesystem subclasses, and there are 
> compatibility streams for FSMemoryFilesystem and FSZipFilesystem. So 
> it's possible to start using Filesystem to replace FileDirectory, and 
> keep using FileStream until the FS stream implementations mature. To put 
> it another way, compatibility with FileStream is a non-goal for the 
> design of the native FS streams, but having a smooth migration path *is* 
> a goal. I've got legacy code that I need to convert!

Thanks. I thought I'd give it a quick try and port the first thing that 
came into my hands which was FileList. Here is some feedback:

 From a Windows perspective, the handling of drives and file systems is 
quite awkward. I would strongly suggest that you drop the idea that 
drives (or shares) are part of the file system and rather move them into 
the path representation. Otherwise you end up with code like here:

   "Figure out the #localName of the directory to display"
   localName := aDirectory path basename.
   "On windows, the local name may be empty and we must look at the
   embedded filesystem's drive field instead"
   (Smalltalk platformName = 'Win32' and:[localName isEmpty])
     ifTrue:[localName := aDirectory filesystem printString].

I mean, eeek. There are several other places where one needs to do stand 
on one's head to do things mixed with drives and paths on Windows which 
will make it significantly harder to write cross-platform code. Just 
consider for example the root directories that we'd like to display in 
the file list. Here is how this looks today:

   roots := FileDirectory root directoryNames.

and now with Filesystem:
   Smalltalk platformName = "Win32"
	ifTrue:[^FSWindowsFilesystem disks collect:[:wfs| wfs root]]
         ifFalse:[^FSDiskFileSystem root entries select:[:d| d 
isDirectory]].

Etc. The problem is fairly persistent and needlessly so given that 
treating the drives and shares like virtual directories gives one 
everything that's needed for dealing nicely with the cross-platform 
aspects while being able to do the Windows-specific stuff just as well. 
What I would propose here is that you keep the filesystem distinction 
(so that someone is able to ask a question like: is this on the same 
file system?) but move the drive letter / share name into the path.

Another issue I found bothersome was FSReference vs. FSPath. It is very 
unclear to me when you use one or the other and given the difficulty to 
distinguish FSPath from FSReference visually I would strongly vote for 
making them one and the same to reduce confusion (see FSFilesystem 
workingDirectory which returns an FSPath vs. FSFilesystem root which 
returns an FSReference etc).

Some smaller issues:
* FSFileSystem root prints incorrectly 'C:/' instead of 'C:\'
* FSWindowsFilesystem>>disks should return an ordered array (C: should 
come before H:)
* There is no #size on FSReadStream?

Other than that I got a basic port of FileList working. It's definitely 
work to port things over, it doesn't come for free. I think there are a 
few things that could help migration significantly, most importantly 
implementing #localName and #fullName on FSReference and 
#modificationTime (in addition to #modificationSeconds) on 
FSDirectoryEntry because they are so commonly used.

Cheers,
   - Andreas