[Vm-dev] Extending primitiveDirectoryEntry

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Fri Apr 21 09:40:48 UTC 2017


2017-04-21 11:28 GMT+02:00 Esteban Lorenzano <estebanlm at gmail.com>:

>
> Hi Alistair,
>
> in the past we extended dir_EntryLookup because a lot of important
> information was missing. With time, I realised that maybe it would have
> been better to add an extra primitive to get extended properties.
> st_dev is not very used but I understand it can be good to have access to
> it.
>
> Then, my question now is: wouldn't be better to add an "extended
> properties” primitive, to answer st_dev and others?
>
> Esteban
>
>
Hi Esteban, from maintenance POV, yes you are right.
A new primitive is better.


> > On 21 Apr 2017, at 10:32, Alistair Grant <akgrant0710 at gmail.com> wrote:
> >
> >
> > Hi All,
> >
> > I'm in the process of making FileReference>>moveTo: work across devices.
> > To make the implementation a bit cleaner on Linux it would be nice to
> > know whether the source and destination reside on the same disk
> > filesystem.  This can be determined by comparing stat.st_dev for the
> > source file and destination directory.
> >
> > dir_EntryLookup() in sqUnixFile.c is exposed as primitiveDirectoryEntry
> > and used by FilePluginPrims>>lookupDirectory:filename:
> >
> > It basically does a stat() on the supplied file and returns most of the
> > resulting information.  Unfortunately st_dev isn't returned.
> >
> > Would there be any objection to me extending the Pharo version of
> > dir_EntryLookup() to include st_dev?
> >
> > Thanks,
> > Alistair
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20170421/104a5d82/attachment.html>


More information about the Vm-dev mailing list