[squeak-dev] Re: [ANN] Filesystem 1.0
Colin Putney
cputney at wiresong.ca
Sun Nov 22 04:57:02 UTC 2009
On 21-Nov-09, at 3:22 PM, Andreas Raab wrote:
> I think you should change the terminology slightly. Having the
> implementation specific thing called "path" and the user visible
> entity called "reference" is confusing - when I was looking at the
> code I saw "oh, there's a path, yeah, that's what I'm looking for".
> The term "reference" didn't ring a bell with me. In other words, I
> would have users deal with FSPath objects and rename the current
> FSPath to something obviously obscure, for example
> "FSPathSequenceImpl" or something to make obviously clear that from
> the user perspective you're going to deal with the FSPath only.
Yes. Terminology is both important and difficult. I'm not very happy
with the term "reference" either, but I can't think of anything
better. The thing I called "path" really is a path, where as
"references" are something more than a path. That said, it may be
wiser to bow to the intuition of users, even though their intuition is
wrong. :-)
>> One fo the advantages of the current arrangement is that all of the
>> filesystem-specific code is a subclass of FSFilesystem. If I start
>> having FSWindowsPath and FSUnixPath and FSZipPath, it gets harder
>> to make things uniform and transparent across different filesystem
>> implementations and harder to extend the system with new filesystems.
>
> Absolutely. But I don't think you'd have to change the arrangement
> at all. The idea is that on Windows there is a virtual root of the
> file system and all shares and drive are logically subdirectories of
> that virtual root. This works fine and really the only difference is
> printing.
I'm not sure I understand the problem with multiple filesystems on
Windows. Sure, you stumbled over some exposed girders trying to
enumerate the available drives, but that doesn't mean the building
isn't structurally sound. Given that there are going to be multiple
filesystem floating around even on unix, it seems to me that the
Windows paradigm of multiple roots is a better fit than the unix
policy of maintaining the illusion of a single root.
I really like your idea of a virtual root directory, but I'm thinking
that instead of having that built into a single FSWindowsFilesystem,
it would be better to reify it and give it the ability to embed other
filesystems within it. That way Windows drive letters can live
alongside in-image filesystems, remote filesystems etc. We already do
that sort of thing when we display superswikis in the FileList. This
solves your problem of how to enumerate the local drives without
Windows-specific code, and allows Unix systems to play as well.
> The assumption that you can tell in a context-free manner whether a
> path is absolute or not will cause grief if you need to be able to
> distinguish /foo/bar from \\share\dir from c:\windows etc. Even more
> tricky, \Windows\system32 is not an absolute path in any meaningful
> way on Windows.
Yeah, this is what convinced me that it's better not to try to paper
over the fact that Windows explicitly has multiple filesystems.
BTW, I disagree with your assertion above. \Windows\system32 *is* an
absolute path; it's just interpreted in the context of the current
drive. Maybe you don't think about the current drive much when using
the Windows Explorer, but that doesn't mean it isn't there.
Here's an experiment that proves it:
1. I opened an Explorer window on my squeak image. In the address bar
it says
C:\Documents and Settings\colin\My Documents\Mason
2. I highlight that and enter 'package-cache'
3. Now the windows shows my MC repository and the address bar says:
C:\Documents and Settings\colin\My Documents\Mason\package-cache
4. That was a relative path! I highlight that and enter '\windows
\system32'
5. Now the window shows a bunch of system files and the address bar
says:
C:\WINDOWS\system32
6. That was an absolute path!
The console behaves the same way when you use cd. The flip side of the
coin is that C:WINDOWS\system32 is a relative path, despite beginning
with a drive letter. If you make D: the current drive in the console,
then do "cd C:WINDOWS\system32" the current directory on drive C: gets
changed but the current drive remains D:. The new current directory on
C: is determined by resolving "WINDOWS\system32" against the old
current directory.
The current implementation gets all this behavior more-or-less for
free, by acknowledging that each drive is really a separate filesystem.
> Ah, what the heck. I just spend two hours fixing things into shape
> the way I think it should work. Attached you'll find my patches
> which implement the above. Check it out and you'll see why I'm
> saying there is no real difference in arrangement. Let me know what
> you think about that direction. The patches allow one to use '\
> \server\path\to\file' as well as 'c:\windows\system' etc. The tests
> pass, too :-)
Thanks. It seems reasonable from quick perusal. I'll respond when I
understand it better.
Colin
More information about the Squeak-dev
mailing list
|