[Vm-dev] Extending primitiveDirectoryEntry

Alistair Grant akgrant0710 at gmail.com
Fri Apr 21 17:17:51 UTC 2017


On Fri, Apr 21, 2017 at 08:13:40AM -0400, David T. Lewis wrote:
>  
> On Fri, Apr 21, 2017 at 11:28:09AM +0200, Esteban Lorenzano wrote:
> >  
> > 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?
> > 
> 
> +1
> 
> I think that is a much better approach.

There appears to be unanimous agreement to refactor this.

The way the primitives are currently used is that there is a method for
each attribute, plus the basic existence.  All of them retrieve the
entire collection of information and pick out the piece they need.

I'm not sure I understand Esteban's suggestion of creating an "extended
properties" primitive, however my suggestion is to add
dir_(Entry)LookupAttribute primitives which take an additional argument:
the index of the attribute to be returned:

	0	File exists
	1	File name
	2	st_mode
	3	st_ino
	4	st_dev
	5	st_nlink
	6	st_uid
	7	st_gid
	8	st_size
	9	st_atime
	10	st_mtime
	11	st_ctime
	12	st_blocks
	13	st_blksize

I'll then refactor the FileSystemStore hierarchy to use the new
primitives.  I can't modify the Windows code, so it will simulate the
new primitive while using the old.

Once Windows has the new primitive implemented, the old will no longer
be called from within the image and, barring any backward compatibility
requirements, could be removed.

Am I missing anything?

Thanks,
Alistair



More information about the Vm-dev mailing list