On Mon, May 27, 2013 at 6:03 AM, David T. Lewis <lewis@mail.msen.com> wrote:
 
- Unix views the file system as a tree, regardless of how many file systems
and physical devices are involved. Windows models this differently as
volumes (C:, D: etc). Other operating systems may have different models.

The first version of FS that I did tried to model that pretty closely. FS its self supports multiple volumes, and so I created one for each Windows drive, each with it's own CWD, just as Windows shells do. People who run Squeak on Windows (particularly Andreas) didn't like this set up, and so we switched it over to a more Unix-like model where there's a single root, single CWD and special handling for the drive letters in absolute paths. I thought it was cool that we could match the Windows filesystem semantics correctly, but <shrug> I'm not a Windows user, what do I know. 
 
- The notions of file creation time, last accessed time, last modified
time and so forth are done differently (and incompatibly) on different
kinds of file system.

The FilePlugin primitives handle the platform differences for us. I haven't run into any issues with this yet.
 
- One operating system may simulaneously host multiple types of file
system, so some of the differences are associated with the file system
and not with the operating system per se.

Filesystem can handle multiple "file systems" at once, so at the image level this isn't an issue (and FS already includes support for file systems  other than the one supplied by the operating system—in memory, inside a zip file etc). If the FilePlugin primitives and/or the OS file API don't unify the interface to different filesystems for us, we could use a different set of primitives for each filesystem. I did have an idea for a new set of primitives to go with the new image-level code, but I figured it'd be better to wait and see what issues, if any, surface from real-world usage.
 
I'm not sure what might be required to have FileSystem work smoothly
with RISC OS as well as Windows/Unix, but I think the effort would be
very worthwhile. Windows and Unix file systems are already very similar,
so the best way to ensure a good level of abstraction is to make sure
that the model also fits file systems such as RISC OS that are not
fundamentally unix-based.

I think the differences in the path syntax should be easy to deal with, but we'll probably need some way to manipulate the file metadata. (eg. to set the filetype correctly).  

So far I have looked at FileSystem only to the extent needed to get
OSProcess/CommandShell working on Pharo, so I don't know if the above
are really relevant. In any case, I'll be happy to help where I can.

Cool!

Colin