This is a great start at a list, Tim!  One thing we really need to think
about, though, is what this is being used for.  We are invariably going
to have a poor representation of  a particular platform's filesystem
using just the generic primitives.  As Tim has pointed out, this isn't
so bad, because we can still have platform-specific subclasses for
people who want to use them (but, please be wary of using them! 
Cross-platform is easy to maintain, but hard to gain once a project
loses it!)

So let's look:


> lineends

Hmm, how about ammending this to "text vs. binary mode"?  The reasoning
is that line-end convention is only needed for dealing with text files,
and as discused in a recent Mac thread, there is also the issue of
character set when manipulating a text file.  If the VM knows whether a
file is in text or binary mode, it can do all necessary translations to
Squeak conventions internally.  (Note, this isn't an encumbrance to
initial porting time (a nice feature of Squaek!): you can leave binary
and text mode the same, to get started.)



Now, a related issue is that we need to decide whether, from Squeak's
perspective, OS text files exist at all!  The alternative is to store
text files in Squeak-specific binaries, even if they happen to look like
text files, and to require text files on the OS to be converted with
some small utility before Squeak reads them.  This has the advantage of
simplicity, and it shouldn't be too hard to deal with.  At any rate,
having half the Squeak community using CrLfFileStream, and the other
half not using it, causes some friction: you can decide for yourself to
use CrLfFileStream, but if your friends are using it, you can't easily
decide *not* to use it.



> filename checking (most platforms have some native api to canonicalize them)

Nice idea.  The main thing is, the code is usually already there: we
just need to use it!  Note, however, that this isn't as big of a deal
once Squeak becomes centered more on projects than whole images: with
project-centrism, people can have base images that are customized for
the local system.  (As things are now, every image has support for every
platform's filename conventions -- and if the main image *doesn't*
support your filesystem, you will have trouble when using other people's
images!)



> file testing (existence, size, permissions, date etc)

Agreed, except for permissions.  What's the cross-platform version of
it?



> file create/rename/remove/link (so far as I can see the four
> mostly-active ports have access to links, what about any others? what to
> do when not there?)

MacOS, MSWindows, and Unix all have links.  Unix has two kinds.  It
sounds more complicated than what Squeak wants, to me, however.  Do they
really behave similarly enough to be useful?  I know you have a use in
mind, but copying works okay for it, and even copying isn't clear to be
necessary in the future.

Simple is very good....  Also, not *every* platform will have links, so
it would suck if code starts relying on their presence.


> read, write, append, truncate
> multiple access - one of my pet peeves is (ab)using files by just
> opening them several times.

What do you mean by multiple access?


> file copying (there's no api to copy a file from one dir to another!)

Yeah, FileCopyPlugin could reasonably be moved into the core file
plugin, if we do a redesign.  I still think the copies will turn out to
be unnecessary, if the makefiles are ever made to be generated from
Smalltalk instead of written by hand, but I know not everyone agrees.


> directory listing/scanning/creating/removing/renaming/linking

Agreed, except that again I'm not sure about linking directories, for
the same reasons as above.


> I'd like to suggest that file names ought to be a class separate from
> file streams, for example.

Yes....  that makes sense!




-Lex