On Apr 22, 2004, at 6:43 PM, Ned Konz wrote:

> But there are lots of cases where one of the tokens wouldn't represent 
> a valid
> path component on another system (or even the same system on a 
> different day
> with different volumes mounted!).

Ok, if I understand correctly, your objection is that it's possible for 
the token sequence to represent an invalid filename. I completely agree 
that this is the case, but I don't understand why it's a problem. I had 
imagined that the Peer would only try to resolve the token sequence 
into a concrete file when necessary, and raise an appropriate error if 
unable to do so. This could be because one or more tokens are invalid, 
or because the user doesn't have permissions for the requested 
operation, or because the indicated file doesn't exist or whatever.

If we make the File smarter, we can sometimes detect the errors sooner, 
but I don't see how that's much of an improvement. Can you explain a 
bit more here?

> I'd recommend that we store more context than just a sequence of 
> Strings.
>
> At least we should be able to know:
>
> * is this an absolute pathname?
> * which of the components represent mounted volumes?
> * which of the components represent directories?
> * what are the rules for file naming at each level of the hierarchy 
> (which is
> required if you're doing filename construction or copying)?
> * what is the character encoding (of course, the String can store this
> information)?

Ok, I think I understand where you want to go, if not why.

So in this case the File would be a sequence of PathComponents, which 
might be instances of Volume, Directory, File and maybe Link. Each of 
these would have a name and references to platform specific state, like 
permissions and naming rules.

> We need to decide:
>
> * how good do we want to be about protecting the users from common 
> mistakes
> and problems? An example of an attempt at this is in the warning on 
> change
> set name length, another is in the filename cleanup code that maps some
> characters into others.
>
> * do we want to know anything about (possibly offline) volumes 
> (removable,
> network, etc.)? If we do, we can prompt to have the volumes put 
> online, or
> can take other actions to do so (i.e. mounting a network share).
>
> * how well do we want to be able to handle links, aliases, and other 
> such
> things?
>
> * do we want to behave differently when traversing the hierarchy when 
> we get
> to a potentially slow (remote or floppy or CD) file system?
>
> * what about permissions? An obvious problem with the logic in 
> fileExists: is
> that a file can exist but not be readable. So you can see its name 
> when you
> enumerate the directory but then fail the readability test. What about
> write-only files?

I think if we go the "rich file path" route that you propose above, we 
should address most if not all of these issues, otherwise I don't think 
the complexity would be worth it. Interesting idea for sure, but 
probably a lot of effort. Really taking advantage of all that detail 
would require a fairly extensive set of primitives, probably covering 
the entire filesystem API of the host platform.

I've noticed that Squeak code doesn't deal with files all that much, at 
least not from what I can see. Is that because with images we don't 
need files much, or because our file system interface sucks?

Colin