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

Alistair Grant akgrant0710 at gmail.com
Sun Jul 30 07:49:07 EDT 2017

Hi All,

I've submitted the FileAttributesPlugin for inclusion in the VM (you can
follow on the vm-dev mailing list if interested).

As Cyril Ferlicot has been quite interested in the file system and its
performance, I thought I might make this available for early testing for
anyone that is interested.

As mentioned previously, the patch:

- Extends the public interface to the file system (FileReference)
  relating to file attributes and iterating over directories
- It doesn't make any changes to existing public behaviour (that I'm
  aware of).
- It does make significant changes to the internals (FileSystem, 
  DiskStore and subclasses)
- Functionality relating to opening & closing files, file IO, etc. isn't

The limitation is that it is only available through the Ubuntu snap,
so you need one of:

- Ubuntu 14.04 or later (16.04 or later preferred)
- A container with Ubuntu 16.04 or later, e.g. Docker
- Can build your own 6.1 or 7.0 VM

If you:

sudo snap install pharo
mkdir fatest
cd fatest
sudo pharo.conf
pharo.ui Pharo.image

And then follow the instructions at: https://github.com/akgrant43/FileAttributes
you'll have the new file attributes code.


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.
> Can someone point me to how to submit a new VM plugin?  The code is 
> contained in a subclass of InterpreterPlugin.
> 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

More information about the Pharo-dev mailing list