[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