Strange error when loading a project into another from a superwiki then saving the image

> I have found this strange error, with squeakland (with up to date  
> update)
>
> If I load a project from a superwiki, then I save the image I got an
> error and the image is not saved.
> It is a primitive error, and it is looking like Squeak try to create a
> /home directory (which it is not authorized to)
>
> If then, I reload the project from the downloaded project in the
> squeaklet directory, then I can save just fine the image.

> Bert Freudenberg a écrit :
>
>> Could you forward the SqueakDebug.log file that was created when  
>> the error occurred?
>
> Here it is.
>
> Hilaire
> Error: a primitive has failed
> 27 February 2007 10:23:28 am
>
> VM: unix - a SmalltalkImage
> Image: Squeakland 3.8-05 [latest update: #552]
>
> SecurityManager state:
> Restricted: true
> FileAccess: false
> SocketAccess: true
> Working Dir /home/hilaire/Documents/CDDP/Animations/2007-03-28/My  
> Squeak
> Trusted Dir /home/hilaire/Documents/CDDP/Animations/2007-03-28/secure
> Untrusted Dir /home/hilaire/Documents/CDDP/Animations/2007-03-28/My  
> Squeak
>
> UnixFileDirectory(Object)>>error:
> Receiver: UnixFileDirectory on '/'
> Arguments and temporary variables:
> t1: 'a primitive has failed'
> Receiver's instance variables:
> pathName: FilePath('/')
>
> UnixFileDirectory(Object)>>primitiveFailed
> Receiver: UnixFileDirectory on '/'
> Arguments and temporary variables:
>
> Receiver's instance variables:
> pathName: FilePath('/')
>
> UnixFileDirectory(FileDirectory)>>primCreateDirectory:
> Receiver: UnixFileDirectory on '/'
> Arguments and temporary variables:
> t1: '/home'
> Receiver's instance variables:
> pathName: FilePath('/')
>
> UnixFileDirectory(FileDirectory)>>createDirectory:
> Receiver: UnixFileDirectory on '/'
> Arguments and temporary variables:
> t1: 'home'
> Receiver's instance variables:
> pathName: FilePath('/')
>
>
> --- The full stack ---
> UnixFileDirectory(Object)>>error:
> UnixFileDirectory(Object)>>primitiveFailed
> UnixFileDirectory(FileDirectory)>>primCreateDirectory:
> UnixFileDirectory(FileDirectory)>>createDirectory:
>  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> UnixFileDirectory(FileDirectory)>>assureExistenceOfPath:
> UnixFileDirectory(FileDirectory)>>assureExistenceOfPath:
> UnixFileDirectory(FileDirectory)>>assureExistenceOfPath:
> UnixFileDirectory(FileDirectory)>>assureExistenceOfPath:
> UnixFileDirectory(FileDirectory)>>assureExistenceOfPath:
> UnixFileDirectory(FileDirectory)>>assureExistenceOfPath:
> UnixFileDirectory(FileDirectory)>>assureExistenceOfPath:
> UnixFileDirectory(FileDirectory)>>assureExistence
> FileDirectory class>>startUp
> FileDirectory class(Behavior)>>startUp:
> [] in SystemDictionary>>send:toClassesNamedIn:with: {[:t6 |  t5 :=  
> self     at: t6     ifAbsent: [].  t5   ifNil: [t4 add: t6]   ...]}
> OrderedCollection>>do:
> SystemDictionary>>send:toClassesNamedIn:with:
> SystemDictionary>>processStartUpList:
> SmalltalkImage>>snapshot:andQuit:embedded:
> SmalltalkImage>>snapshot:andQuit:
> SmalltalkImage>>saveSession
> TheWorldMenu>>doMenuItem:with:
> [] in MenuItemMorph>>invokeWithEvent: {[(t2 := selector numArgs) =  
> 0   ifTrue: [target perform: selector]   ifFalse...]}
> BlockContext>>ensure:
> CursorWithMask(Cursor)>>showWhile:
> MenuItemMorph>>invokeWithEvent:
> MenuItemMorph>>mouseUp:
> MenuItemMorph>>handleMouseUp:
> MouseButtonEvent>>sentTo:
> MenuItemMorph(Morph)>>handleEvent:
> MorphicEventDispatcher>>dispatchDefault:with:
> MorphicEventDispatcher>>dispatchEvent:with:
> MenuItemMorph(Morph)>>processEvent:using:
> MorphicEventDispatcher>>dispatchDefault:with:
> MorphicEventDispatcher>>dispatchEvent:with:
> MenuMorph(Morph)>>processEvent:using:
> MenuMorph(Morph)>>processEvent:
> MenuMorph>>handleFocusEvent:
> [] in HandMorph>>sendFocusEvent:to:clear: {[ActiveHand := self.  
> ActiveEvent := t1.  t4 := t2     handleFocusEvent: (t1...]}
> [] in PasteUpMorph>>becomeActiveDuring: {[t1 value]}
> BlockContext>>on:do:
> PasteUpMorph>>becomeActiveDuring:
> HandMorph>>sendFocusEvent:to:clear:
> HandMorph>>sendEvent:focus:clear:
> HandMorph>>sendMouseEvent:
> HandMorph>>handleEvent:
> HandMorph>>processEvents
> [] in WorldState>>doOneCycleNowFor: {[:t3 |  ActiveHand := t3.  t3  
> processEvents.  t2 := t2     or: [t3 isCapturi...]}
> Array(SequenceableCollection)>>do:
> WorldState>>handsDo:
> WorldState>>doOneCycleNowFor:
> WorldState>>doOneCycleFor:
> PasteUpMorph>>doOneCycle
> [] in Project class>>spawnNewProcess {[[World doOneCycle.  
> Processor yield.  false] whileFalse.  nil]}
> [] in BlockContext>>newProcess {[self value.  Processor  
> terminateActive]}
> _______________________________________________
> Squeakland mailing list
> [hidden email]
> http://squeakland.org/mailman/listinfo/squeakland

> No Bert my directory is not write protected, let me explain the
> operation I conducted:
>
> - working in my squeakland image (a copy of it in another folder than
> the default one, and I start it with squeakvm)
> - I create and edit my project with this image, I can save the image
> just fine
> - I load a project from our swiki (with my squeakland configure  
> with the
> smalltalk code at http://superswiki.ofset.org:8000/super/16)
> - I save the image ==> error. From there whatever I do (remove the
> loaded project), I cannot save the image
> - I quit squeak and restart it, with the last saved image (before  
> the bang)
> - I reload the downloaded project, but from the local copy now in 'My
> Squeak, This time I can save the image just fine.
>
> Hope it helps,
>
> Hilaire
>
>
> Bert Freudenberg a écrit :
>> Thanks. Is it possible your image directory was write-protected? The
>> log indicates it was trying to create the default directory but
>> failed. I can't imaging how that could have to do with the project
>> loaded, unless it fiddled with the default directory path.
>>
>
>
> _______________________________________________
> Squeakland mailing list
> [hidden email]
> http://squeakland.org/mailman/listinfo/squeakland

> Sure, it is trying to create the /home directory, odd don't you? At  
> first I was wondering if I was analysing correcty.
>
> I load a .pr which does not produce this problem.
> Form superwiki ofset.org:8000
>
> - the pb arised with 'v-toys voiture sur route-7.pr'
> - the does not arise with 'modele de diapo inter-2'
>
> Both project are at top of the list.
>
> Does it produce the same pb for you?
>
> Hilaire
>
> Bert Freudenberg a écrit :
>> Okay, so you can reproduce this. In the debugger, can you check  
>> which directory it's actually trying to ensure exists? And find  
>> out why that fails?
>
>

>
> - Bert -
>
>
> On Mar 2, 2007, at 12:41 , Hilaire Fernandes wrote:
>
>> Sure, it is trying to create the /home directory, odd don't you? At
>> first I was wondering if I was analysing correcty.
>>
>> I load a .pr which does not produce this problem.
>> Form superwiki ofset.org:8000
>>
>> - the pb arised with 'v-toys voiture sur route-7.pr'
>> - the does not arise with 'modele de diapo inter-2'
>>
>> Both project are at top of the list.
>>
>> Does it produce the same pb for you?
>>
>> Hilaire
>>
>> Bert Freudenberg a écrit :
>>> Okay, so you can reproduce this. In the debugger, can you check which
>>> directory it's actually trying to ensure exists? And find out why
>>> that fails?
>>
>>
>
>

> Bert Freudenberg a écrit :
>> No, what I mean is, what directory was it trying to create originally.
>> You have to look in the debugger stack where the first assureExistence
>> is called to see that directory.
>
> Strangely it was not clear as I did not see any absolute pathname, only
> successive directory. However it was looking like it starts down from
> 'My Squeak' folder. I will give it a serious check later next week as I
> was in hurry recently.
>
> Hilaire
>
>
>> - Bert -
>>
>>
>> On Mar 2, 2007, at 12:41 , Hilaire Fernandes wrote:
>>
>>> Sure, it is trying to create the /home directory, odd don't you? At
>>> first I was wondering if I was analysing correcty.
>>>
>>> I load a .pr which does not produce this problem.
>>> Form superwiki ofset.org:8000
>>>
>>> - the pb arised with 'v-toys voiture sur route-7.pr'
>>> - the does not arise with 'modele de diapo inter-2'
>>>
>>> Both project are at top of the list.
>>>
>>> Does it produce the same pb for you?
>>>
>>> Hilaire
>>>
>>> Bert Freudenberg a écrit :
>>>> Okay, so you can reproduce this. In the debugger, can you check which
>>>> directory it's actually trying to ensure exists? And find out why
>>>> that fails?
>>>

> Recheck again at home and I can reproduce the same problem.
>
> Load from swiki a project then save image under a different name, so:
>
> Smalltlalk>>saveImageinFileName:t1
> t1='/home/hilaire/.npsqueak/My Squeak/SqueakPlugin.1.image'
>
> Then the recursive call of 'assureExistenceOfPath: t1' go up to home,
> then the call primCreateDirectory t1 with t1='/home'
> It is then primitive land, which I don't know
>
> I will look at the OLPC version.
>
> Hilaire
>
>
>
> Hilaire Fernandes a écrit :
>> Bert Freudenberg a écrit :
>>> No, what I mean is, what directory was it trying to create  
>>> originally.
>>> You have to look in the debugger stack where the first  
>>> assureExistence
>>> is called to see that directory.
>>
>> Strangely it was not clear as I did not see any absolute pathname,  
>> only
>> successive directory. However it was looking like it starts down from
>> 'My Squeak' folder. I will give it a serious check later next week  
>> as I
>> was in hurry recently.
>>
>> Hilaire
>>
>>
>>> - Bert -
>>>
>>>
>>> On Mar 2, 2007, at 12:41 , Hilaire Fernandes wrote:
>>>
>>>> Sure, it is trying to create the /home directory, odd don't you? At
>>>> first I was wondering if I was analysing correcty.
>>>>
>>>> I load a .pr which does not produce this problem.
>>>> Form superwiki ofset.org:8000
>>>>
>>>> - the pb arised with 'v-toys voiture sur route-7.pr'
>>>> - the does not arise with 'modele de diapo inter-2'
>>>>
>>>> Both project are at top of the list.
>>>>
>>>> Does it produce the same pb for you?
>>>>
>>>> Hilaire
>>>>
>>>> Bert Freudenberg a écrit :
>>>>> Okay, so you can reproduce this. In the debugger, can you check  
>>>>> which
>>>>> directory it's actually trying to ensure exists? And find out why
>>>>> that fails?
>>>>

> Bert Freudenberg wrote:
>> The debug log you attached before shows that your image was in  
>> restricted mode. In this sandbox mode, you are only allowed to  
>> write  inside the SecurityManager's "untrusted directory". I don't  
>> think  you're even supposed to save the image when in sandbox  
>> mode, so if  you try anyway, there might be any number of bugs  
>> lurking. IIRC the  image save logic assumes that FileDirectory  
>> default and the image  directory are identical. But in sandbox  
>> mode, this is not true anymore.
>
> That is correct. With the sandbox on, you can't safe the image -  
> otherwise this would be a trivial way for a malicious bit of code  
> to make itself forever at home in that image.