<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, May 27, 2013 at 6:03 AM, David T. Lewis <span dir="ltr"><<a href="mailto:lewis@mail.msen.com" target="_blank">lewis@mail.msen.com</a>></span> wrote:<br>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- Unix views the file system as a tree, regardless of how many file systems<br>
and physical devices are involved. Windows models this differently as<br>
volumes (C:, D: etc). Other operating systems may have different models.<br></blockquote><div><br></div><div style>The first version of FS that I did tried to model that pretty closely. FS its self supports multiple volumes, and so I created one for each Windows drive, each with it's own CWD, just as Windows shells do. People who run Squeak on Windows (particularly Andreas) didn't like this set up, and so we switched it over to a more Unix-like model where there's a single root, single CWD and special handling for the drive letters in absolute paths. I thought it was cool that we could match the Windows filesystem semantics correctly, but <shrug> I'm not a Windows user, what do I know. </div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- The notions of file creation time, last accessed time, last modified<br>
time and so forth are done differently (and incompatibly) on different<br>
kinds of file system.<br></blockquote><div><br></div><div style>The FilePlugin primitives handle the platform differences for us. I haven't run into any issues with this yet.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- One operating system may simulaneously host multiple types of file<br>
system, so some of the differences are associated with the file system<br>
and not with the operating system per se.<br></blockquote><div><br></div><div style>Filesystem can handle multiple "file systems" at once, so at the image level this isn't an issue (and FS already includes support for file systems other than the one supplied by the operating system—in memory, inside a zip file etc). If the FilePlugin primitives and/or the OS file API don't unify the interface to different filesystems for us, we could use a different set of primitives for each filesystem. I did have an idea for a new set of primitives to go with the new image-level code, but I figured it'd be better to wait and see what issues, if any, surface from real-world usage.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'm not sure what might be required to have FileSystem work smoothly<br>
with RISC OS as well as Windows/Unix, but I think the effort would be<br>
very worthwhile. Windows and Unix file systems are already very similar,<br>
so the best way to ensure a good level of abstraction is to make sure<br>
that the model also fits file systems such as RISC OS that are not<br>
fundamentally unix-based.<br></blockquote><div><br></div><div style>I think the differences in the path syntax should be easy to deal with, but we'll probably need some way to manipulate the file metadata. (eg. to set the filetype correctly). </div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">So far I have looked at FileSystem only to the extent needed to get<br>
OSProcess/CommandShell working on Pharo, so I don't know if the above<br>
are really relevant. In any case, I'll be happy to help where I can.<br></blockquote><div><br></div><div style>Cool!</div><div style><br></div><div style>Colin </div></div></div></div>