On Apr 22, 2004, at 4:55 PM, Ned Konz wrote:

> On Thursday 22 April 2004 1:10 pm, Colin Putney wrote:
>> Lets assume that the file system is hierarchical. (We don't currently
>> support any that aren't, do we?) File could contain an isAbsolute 
>> flag,
>> and an array of tokens. The peer for the current filesystem would take
>> those tokens and do some kind of platform-specific resolution.
>
> I don't think it's that simple. I believe that's what Java does, and I 
> don't
> think it ensures portability.
>
> I have a Perl module (Archive::Zip) on CPAN, and I've had to deal with
> filename mapping problems on several platforms. It's not easy. As you 
> recall,
> filenames are stored in a canonical but poorly-specified format in Zip 
> files;
> they use forward slashes as directory separators but it's otherwise 
> not well
> defined what they can consist of.
>
> For the Mac (HFS) and Windows platforms I had to add some knowledge of
> volumes; these don't necessarily work like ordinary path components. 
> That is,
> you may need to know where the mount points are (and possibly about 
> volume
> aliasing as well if you have a file system like the Amiga OS). Some 
> file
> operations work differently across volume boundaries, and it's also 
> possible
> (I think) to have a combination of file systems with different rules 
> mounted
> into a single namespace.
>
> For instance, I use Samba to serve files from my Linux box, and also 
> use
> SMB/CIFS to share files from my Windows and Mac machines. But these 
> three
> worlds have different file naming rules and could have different 
> handling of
> names (maximum length, allowed characters, NLS/character encoding, case
> sensitivity, case preservation) as well as other incompatible
> characteristics.

I'm not sure I understand what the problem is.

Clearly, there are some filenames/locations that will be valid on some 
platforms but not others. There's nothing we can do about that. At the 
same time, we might not be able to take full advantage of a particular 
file system's capabilities. A file system might be able to have Unicode 
filenameds, but we're still going to be representing them in MacRoman 
in Squeak. (For now at least, the m17n stuff might change that.) So?

If the user tries to create or access a file with a name that's not 
valid on the current platform we throw an error. What's wrong with 
that? If the filename isn't valid, there's not going to be a file there 
anyway, right?

Are you suggesting that a sequence of tokens is not sufficient to 
represent the location of a file on some filesystems? That *would* be a 
show stopper for this scheme.

I *think* that things like volumes and mount points can be encoded in 
the sequence of tokens. Is there a reason #('Macintosh HD' 'System 
Folder' 'Finder') couldn't be treated by the HfsFilePeer as a volume 
name followed by a folder name and a file name? Obviously the 
Win32FilePeer wouldn't like this at all, but even we automagically 
handled the volumes correctly, there wouldn't be a file at C:\System 
Folder\Finder anyway.

Also note the difference between relative and absolute file references. 
There's a good chance an absolute file reference won't be valid if you 
move the image to another machine, let alone another platform. So we're 
going to have to throw FileNotFound exceptions. And if we're doing 
that, why not InvalidFilename as well?

OTOH, a it's perfectly reasonable to have a reference relative to the 
image keep working if you move both the image and the referenced file 
to another machine running a different OS. This is a common case that 
is broken now, but would work fine with the sequence-of-tokens idea.

Does this make any sense?

Colin