[Vm-dev] [Pharo-dev] issue with large file path on windows

David T. Lewis lewis at mail.msen.com
Wed Sep 16 00:11:26 UTC 2015


On Tue, Sep 15, 2015 at 10:45:16AM -0700, Eliot Miranda wrote:
>  
> Hi David,
> 
> On Tue, Sep 15, 2015 at 5:45 AM, Esteban Lorenzano <estebanlm at gmail.com>
> wrote:
> 
> >
> > > On 15 Sep 2015, at 14:13, David T. Lewis <lewis at mail.msen.com> wrote:
> > >
> > >
> > > On Tue, Sep 15, 2015 at 11:40:48AM +0200, Esteban Lorenzano wrote:
> > >>
> > >> Pharo uses them.
> > >>
> > >> Posix permissions are useful for both linux and mac.
> > >> Windows uses also the posix permissions that came with MinGW??? I do
> > not think they are useful but we provide them anyway :)
> > >
> > >
> > > Posix permissions are based on Unix, and are very platform specific. The
> > > Windows equivalents are semantically different, and other operating
> > systems
> > > may exist that are not Unix based at all.
> > >
> > > IMO, platform specific functions should go into separate plugins, and not
> > > in FilePlugin.
> >
> > well, I disagree :)
> > I do not find this approach practical??? because in general, there is no
> > other systems that may exist using other permissions than POSIX. Except
> > Windows, of course, but even for windows, there are compatibility layers
> > that we can use.
> > In the case of the FilePlugin extensions, we choose to stay POSIX because
> > in general, as its been said before, the job of a virtual machine is been
> > virtual: to provide an ???abstract machine??? common for everything in the
> > image. I???m not saying that this is possible and even desirable in all
> > cases, but it should be something to think about.
> > In that case, we could design a common file permissions different to the
> > one of Windows and different to POSIX, but I think POSIX does the job just
> > fine.
> >
> > Also, the choice was: POSIX or nothing (because we didn???t have anything
> > before).
> > I would be very happy if we agree in a better solution, and we implement
> > it.
> > But in the mean time, a not perfect solution is better than none.
> >
> 
> I agree with Esteban.  IMO, the model of files that the FilePlugin provides
> access to can and should be a superset of facilities.  By not supporting
> facilities such as permissions or symbolic links or active mount-points we
> hobble our core file functionality and that makes us a very weak scripting
> platform.  Putting these facilities in add-on packages makes configuration
> more difficult and means that an elegant implementation in the core file
> classes, with fallbacks for platforms that don't support the concepts, is
> very difficult.

I do not intend to suggest that these things are not wonderful and good
and worthy of being done. What I said is that they should not be put into
FilePlugin.

Yes it is more difficult to implement features like this in packages, but
with all due respect it's not all *that* terribly hard. And I think the
too much work argument does not hold up when we are talking about something
like FilePlugin that effectively defines minimal core functionality required
to bring up an image on a new platform.

> 
> If we want to support unix-style scripting in Pharo and Squeak (and I think
> we very much do; there are many areas out there where good scripting is
> essential) then we need a better File model, and that means not just
> getting rid of FileDirectory et al, it also means providing the right
> infrastructure in the FilePlugin, and that means extensions like the one
> the Pharo VM folks made.  Indeed they haven't gone nearly far enough IMO.

Again, I am not saying that these things should not be done. Just that
with respect to platform-specific features that can only ever work
on a Unix based system, allowing these to creep into the feature set of
base system does not seem like a very good idea to me. That's all I am
saying.

Dave



More information about the Vm-dev mailing list