FileDirectory>>fileExists: (was: Re: [BUG]Unable to load BFAV,
various problems )
Colin Putney
cputney at wiresong.ca
Thu Apr 22 22:35:57 UTC 2004
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
More information about the Squeak-dev
mailing list
|