[Vm-dev] [Pharo-dev] FileSystem file attributes and #isSymlink patch

[David T. Lewis]

Hi Alistair,

I am copying this to vm-dev for follow up on the plugin, see below.


On Mon, Jul 24, 2017 at 08:09:10AM +0000, Alistair Grant wrote:
> Hi All,
> 
> I'm nearly ready to submit a patch that started with the goal of being
> able to retrieve the device id and fixing FileReference>>isSymlink and 
> also follows Esteban's suggestion of splitting out file existence and 
> other attributes (which provides a performace gain).  See the summary
> below for a description of the changes.
> 
> The patch involves adding a new VM plugin, FileAttriubutesPlugin.  To 
> minimise the chance of any problems along the way I'd like to submit the 
> patch in three steps:
> 
> 1. Add the VM plugin (FileAttributesPlugin)
> 2. Add the code the image that allows testing of the code and plugin, 
>    but doesn't do any integration with existing functionality.
>    This will allow the plugin to be tested by a few volunteers 
>    (hopefully).
> 3. Add the patches that make the switch over to the new implementation.
> 

I think you are handling this in exactly the right way, kudos.

> 
> Can someone point me to how to submit a new VM plugin?  The code is 
> contained in a subclass of InterpreterPlugin.

Following up on the vm-dev list: If your plugin is available in a Monticello
repository, that would be great because VM builders can easily include it
and try it out. Any repository would be fine for starters, or if you have
an account on squeaksource.com I can add you as developer in the somewhat
loosely-related DirectoryPlugin project if that is of any help. Whatever is
convenient for you.

Your plugin sounds like something that would be stable and require little
maintenance over time, so it might make sense to pull it directly into
the VMMaker package. We can discuss that vm-dev list.

Once your plugin code is available, it should be straighforward to start
including it in the various VM build configurations.

Dave


> 
> I've been using this as my production environment for about 2 months now 
> on a linux 32 bit VM.  Running the full test suite results in the same 
> set of test failing before and after applying the patch.
> 
> I've also ran file related tests on linux 64 bit (run the Test Runner, 
> select all packages with "file" as part of the name and run all the 
> available tests) and the full test suite on Windows 32 bit.
> 
> The summary is:
> 
> 1. #isSymlink now works properly on Linux (and it should also work on 
>    MacOS and BSD).
> 2. The list of file attributes available from FileReference now is:
> 	#accessTime (new)
> 	#changeTime (new)
> 	#creationTime
> 	#deviceId (new)
> 	#exists
> 	#gid (new)
> 	#inode (new)
> 	#isBlock (new)
> 	#isCharacter (new)
> 	#isDirectory
> 	#isExecutable (new)
> 	#isFIFO (new)
> 	#isFile
> 	#isReadable
> 	#isRegular (new)
> 	#isSocket (new)
> 	#isSymlink (works)
> 	#isWritable
> 	#modificationTime
> 	#numberOfHardLinks (new)
> 	#permissions
> 	#size
> 	#targetFile (new)
> 	#uid (new)
> 3. FileReference>>exists is faster than before (well, at least on my 
>    linux laptop).  This is useful as it is called quite often.
> 4. It is possible to retrieve symbolic link attributes, e.g. all the 
>    attributes listed above plus the target path.
> 
> 
> Given how similar MacOS and BSD are to linux, I assume that this will 
> all work without problem on those platforms (but it obviously needs to 
> be tested).
> 
> As implied above, the changes are all backward compatible (except 
> the broken #isSymlink), although a couple deserve mention:
> 
> 1. Obviously #isSymlink now answers correctly (previously it would only 
>    answer correctly for a broken link).
> 2. Requesting any of the attributes listed above (except #isSymlink) 
>    will return the value of the target path.  If the FileReference is to a 
>    broken symbolic link, it will return the attributes of the symbolic 
>    link (keeping existing behaviour).
> 3. The attributes of a symbolic link can be retrieved using 
>    FileReference>>symlinkAttributes.
> 
> Overall, performance is slightly better than before.  Code that
> needs to access multiple attributes and is written to take advantage of 
> the new behaviour will see significant performance improvements.
> 
> 
> If you've got this far and forgotten the original question :-)
> 
> Can someone point me to how to submit a new VM plugin?
> 
> 
> Thanks,
> Alistair