It appears that there's a behavior difference between recent Cog and Pharo/Seaside (which I assume is just the Squeak VM?) VMs: <primitive: 'primitiveDirectoryEntry' module: 'FilePlugin'> returns 5 values in Cog and 7 in Squeak. The 6th value are the file permissions and the 7th is a boolean (haven't looked to see what it represents). I noticed this with some Pharo and Seaside images when attempting to open the world menu -> Tools -> File Browser which results in an error under Cog. The cause is DiskStore #basicEntryAt: returning 2 additional values that Cog currently does not: [plug := FilePluginPrims new. path := AbsolutePath from: '/tmp'. ds := DiskStore current. ds basicEntryAt: path] value. Squeak VM returns: #('tmp' 3606072933 3606072933 true 0 511 false) Cog VM returns: #('tmp' 3606072933 3606072933 true 0) These results were obtained using the VMs from http://www.seaside.st/distributions/Seaside-3.1-OneClick-Pharo2.zip and http://www.mirandabanda.org/files/Cog/VM/VM.r3308/coglinux-15.14.3308.tgz I'm assuming this is not an intentional behavior difference. But if it is, any details as to why would be appreciated... Thanks, Phil |
2015-04-10 5:30 GMT+02:00 Phil (list) <[hidden email]>:
No, it is pharo only. Pharo changed the fileplugin because it has a different abstraction for the platform file system. Instead of the squeak classes FileDirectory/DirectoryEntry... it uses the newer in FileSystem-/Disk/Store/Memory. This File API and the underlaying FilePlugin provide more file attributes (Permissions and isSymlink) VMs: <primitive: |
as Nicolai said, this is not the squeak vm but the pharo vm (which is a Cog, too).
we added posix permissions and symlink flag. and we changed it not because we have a different abstraction, we changed because information was not enough. we will add also owner and group soon also, but most probably it will be cheers, Esteban
|
I'll also add that Esteban, Camillo and others did that change with the intention of being backwards compatible. Why does it break in squeak? is somebody checking that the returned array has 5 elements (and no more)? Guille El vie., 10 de abr. de 2015 a la(s) 11:30 a. m., Esteban Lorenzano <[hidden email]> escribió:
|
In reply to this post by EstebanLM
“most probably it will be a different primitive”… I wend for coffee without finishing the sentence ;)
|
In reply to this post by Guillermo Polito
First, thanks to all for the information and clarification. I wasn't aware that Pharo was using its own 'flavor' of VM... now I know better. Guille, On Fri, 2015-04-10 at 09:39 +0000, Guillermo Polito wrote: > > I'll also add that Esteban, Camillo and others did that change with > the intention of being backwards compatible. Why does it break in > squeak? is somebody checking that the returned array has 5 elements > (and no more)? > I noticed it as a result of a problem opening the File Browser due to the missing metadata and Pharo silently ignoring the problem until it couldn't anymore (MNU due to a couple of nil objects). When I went back through the code, the following DiskStore method was the culprit: basicPosixPermissions: anEntry ^ (anEntry size >= 6) ifTrue: [ anEntry at: 6 ] ifFalse: [ nil ]. Since it sounds like the VM divergence is likely to be around for the foreseeable future and assuming check above is how Pharo wants to handle the situation, it would have been nice if ifFalse: in the above did just about anything other than returning nil. For example, it would have been helpful if an exception had been raised indicating something along the lines of "Metadata missing (not running under Pharo VM?)". Granted, it's an ugly solution... but it seems better than the above code since returning nil only served to obfuscate the source of the problem down the line. Another option might be to go to the source of the data in anEntry and look at doing something with #basicEntryAt: > Guille > Thanks, Phil > El vie., 10 de abr. de 2015 a la(s) 11:30 a. m., Esteban Lorenzano > <[hidden email]> escribió: > > On 10 Apr 2015, at 09:37, Nicolai Hess <[hidden email]> > > wrote: > > > > > > > > 2015-04-10 5:30 GMT+02:00 Phil (list) <[hidden email]>: > > > > It appears that there's a behavior difference > > between recent Cog and > > Pharo/Seaside (which I assume is just the Squeak > > VM?) > > > > > > No, it is pharo only. > > > > Pharo changed the fileplugin because it has a different > > abstraction > > > > for the platform file system. > > > > Instead of the squeak classes > > FileDirectory/DirectoryEntry... > > > > it uses the newer in FileSystem-/Disk/Store/Memory. > > > > > > This File API and the underlaying FilePlugin provide > > > > more file attributes (Permissions and isSymlink) > > > > > > > > VMs: <primitive: > > 'primitiveDirectoryEntry' module: 'FilePlugin'> > > returns 5 values in Cog > > and 7 in Squeak. The 6th value are the file > > permissions and the 7th is > > a boolean (haven't looked to see what it > > represents). > > > > I noticed this with some Pharo and Seaside images > > when attempting to > > open the world menu -> Tools -> File Browser which > > results in an error > > under Cog. The cause is DiskStore #basicEntryAt: > > returning 2 additional > > values that Cog currently does not: > > > > [plug := FilePluginPrims new. > > path := AbsolutePath from: '/tmp'. > > ds := DiskStore current. > > ds basicEntryAt: path] value. > > > > > > Squeak VM returns: #('tmp' 3606072933 3606072933 > > true 0 511 false) > as Nicolai said, this is not the squeak vm but the pharo vm > (which is a Cog, too). > > > > > Cog VM returns: #('tmp' 3606072933 3606072933 true > > 0) > > > > These results were obtained using the VMs from > > http://www.seaside.st/distributions/Seaside-3.1-OneClick-Pharo2.zip and > > http://www.mirandabanda.org/files/Cog/VM/VM.r3308/coglinux-15.14.3308.tgz > > > > I'm assuming this is not an intentional behavior > > difference. But if it > > is, any details as to why would be appreciated… > we added posix permissions and symlink flag. > and we changed it not because we have a different abstraction, > we changed because information was not enough. > we will add also owner and group soon also, but most probably > it will be > > > cheers, > Esteban > > > > > Thanks, > > Phil > > > > > > > > |
Free forum by Nabble | Edit this page |