[Vm-dev] Re: [Pharo-dev] PharoLauncher on Windows not the latest version

Nicolai Hess nicolaihess at web.de
Thu Sep 4 20:18:25 UTC 2014

2014-09-04 18:53 GMT+02:00 Ben Coman <btc at openinworld.com>:

>  I can confirm this behaviour.  It looks like FilePlugin cannot 'rename'
> a folder across drives, although it can rename a file across drives. A hack
> to demonstrate from Workspace...
> filePlugin := FilePluginPrims allInstances first.
> filePlugin  rename: 'C:\Temp\Test\file1.txt' to:
> 'C:\Temp\Test\file2.txt'.  "-->sucess"
> filePlugin rename: 'E:\Temp\Test\file1.txt' to: 'E:\Temp\Test\file2.txt'.
> "-->sucess"
> filePlugin rename: 'C:\Temp\Test\file2.txt' to: 'E:\Temp\Test\file3.txt'.
> "-->sucess"
> filePlugin rename: 'C:\Temp\Test\folder1' to: 'C:\Temp\Test\folder2'.
> "-->sucess"
> filePlugin rename: 'E:\Temp\Test\folder1' to: 'E:\Temp\Test\folder2'.
> "-->sucess"
> filePlugin rename: 'C:\Temp\Test\folder2' to: 'E:\Temp\Test\folder3'.
> "-->fail"
> I think that is more of a design constraint that a bug.  VBscript has a
> similar problem [1]. I cloned Pharo-vm off github and in
> ".../platforms/wind32/plugins/FilePlugin/sqWin32FilePrims.c" found function
> sqFileRenameOldSizeNewSize uses win32api function MoveFileW which is
> documented [2] as "The MoveFile function will move (rename) either a file
> or a directory (including its children) either in the same directory or
> across directories. The one caveat is that the MoveFile function will fail
> on directory moves when the destination is on a different volume."
> Unix platforms don't encounter this since all volumes are mounted under
> one root.  (e.g. OSX mounting usb drives under /Volumes). I guess the Unix
> equivalent might be renaming to folder across network shares, though I'm
> not familiar with how different OS's handles that.

No, there is a similiar limitation on linux as well. Even if all
directories are under a common root dir, moving files across different
harddisks/partitions doesn't work:

12992 Cannot move files to another volume / partition under linux

unix/linux vm uses the system library call rename() for moving files but
this function
results in an error
EXDEV  'Invalid cross-device link'
if the two file names newname and oldname are on different file systems.

> However we should consider consistency across platforms.  Cross volume
> folder renames could be checked for, and modified to a copy/delete
> strategy. To state the obvious, the options of where to do this are:
> a. In PharoLauncher
> b. In Pharo in
> WindowsStore(FileSystemStore)>>rename:ifAbsent:to:ifPresent:fileSystem:
> c. In VM
> Off the cuff, I'd vote for (b.), but others will better idea of the
> approach to take. Now if indeed a copy/delete fallback strategy is
> considered beneficial, it would need to consider how timestamps are handled.
> [1]
> https://groups.google.com/forum/#!topic/microsoft.public.scripting.vbscript/gz7mv5r50xs
> [2]
> http://msdn.microsoft.com/en-us/library/windows/desktop/aa365239(v=vs.85).aspx
> cheers -ben
> btw, Since this was my first time looking a VM code, I'm happy to report
> it was dead easy to clone pharo-vm from github and review (without yet
> trying to compile). Actually I cloned on OSX so I could `find` the win32
> FilePlugin code.
> kilon alios wrote:
> So I manage to get Launcher running with downloading pharolauncher zip and
> then downloading pharo 3 and joining the two folders. Launcher now runs but
>  I dont want it to store images in my c drive so I go to preferences and
> tell it where in my D drive to save images (D:\software\PharoImages) I
> press enter and I am getting this error
>  WindowsStore(Object)>>primitiveFailed:
> WindowsStore(Object)>>primitiveFailed
> WindowsStore(FileSystemStore)>>rename:ifAbsent:to:ifPresent:fileSystem:
> FileSystem>>rename:ifAbsent:to:ifPresent:
> FileSystem>>rename:to:
> FileReference>>moveTo:
> PhLRelocateImageDirectoryCommand>>execute in Block: [ :child | child
> moveTo: (self target resolvePath:...etc...
> Array(SequenceableCollection)>>collect:
> PhLRelocateImageDirectoryCommand>>execute
> PhLRelocateImageDirectoryCommand>>executeOrInform
> PhLDirectoryBasedImageRepository class>>migrateFrom:to:
> PhLDirectoryBasedImageRepository class>>location:
> PhLDirectoryBasedImageRepository class>>locationString:
> SettingDeclaration>>realValue:
> SettingDeclaration>>index:
> EditableDropListMorph(DropListMorph)>>listSelectionIndex:
> EditableDropListMorph>>content:
> PluggableTextFieldMorph>>acceptTextInModel
> PluggableTextFieldMorph(PluggableTextMorph)>>acceptBasic
> PluggableTextFieldMorph>>accept
> TextMorphForFieldView(TextMorphForEditView)>>acceptContents
> TextEditor>>accept
> TextMorphForFieldView(TextMorphForEditView)>>keyStroke:
> TextMorphForFieldView>>keyStroke:
> TextMorphForFieldView(TextMorph)>>handleKeystroke:
> KeyboardEvent>>sentTo:
> TextMorphForFieldView(Morph)>>handleEvent:
> TextMorphForFieldView(Morph)>>handleFocusEvent:
> HandMorph>>sendFocusEvent:to:clear: in Block: [ ...
> BlockClosure>>on:do:
> On Mon, Sep 1, 2014 at 12:06 PM, kilon alios <kilon.alios at gmail.com>
> wrote:
>> I am not back to my work pc, so if you have any ideas how to proceed I am
>> open to suggestions.
>> On Thu, Aug 28, 2014 at 5:17 PM, Tim Mackinnon <tim at testit.works> wrote:
>>> Kilon - it would be good if we could percevear to try and get a fix and
>>> detailed instructions for other less confident users… At least test Ben’s
>>> updated installer so we can clear this.
>>>  I appreciate the aggravation you are putting up with.
>>>  Tim
>>>  On 28 Aug 2014, at 10:35, kilon alios <kilon.alios at gmail.com> wrote:
>>>  My work pc is dual boot to ubuntu and win 7 . I am not a fan of linux
>>> either, loads of problems there but nowhere near as bad as windoom.
>>>  I need windoom because of a Greek OCR I use at work to scan legal
>>> documents. I have no choice other than to continue using it.
>>>  I dont care what the corporate world does or the fact that almost 100%
>>> of my fellow lawyers use windoom and some still DOS. Thats their problem :D
>>>  It would be nice to support what 95% of people use out there, but alas
>>> I cant take it anymore. Coding should be fun, Windoom kills my inner child.
>>> Sorry for those that have to tolerate this crap, but I am lucky enough not
>>> to .
>>>  /ranting off
>>> On Thu, Aug 28, 2014 at 11:50 AM, Ben Coman <btc at openinworld.com> wrote:
>>>> kilon alios wrote:
>>>>> ok thing get worse and worse
>>>>> I try to run pharo as administrator and pharo opens and exits
>>>>> immediately , it creates a stderr which contains the following
>>>>> http://pastebin.com/v9Hpx9pK
>>>>> I found the folder you mentioned and I deleted it , now pharo does not
>>>>> open at all even when run without "run as administrator"
>>>>> Boy I hate Windoom. I also tried Tim link , nothing, pharo opens but
>>>>> does nothing, no gui, nothing. I know it opens because i can see its
>>>>> process in the task manager which i have to terminate manually.
>>>>> I do all my coding and art on macos, I only have windows at work so i
>>>>> can test my code on windoom too, but this was the last straw, I had enough
>>>>> with this uber crappy OS for 17 years now. I am dropping support for it and
>>>>> sticking to MacOS only.
>>>>> Thanks guys for your help but it does not worth it. I hope no other
>>>>> windows user experience my problem.
>>>>  I empathize.  I've been a Linux advocate for years, but never made the
>>>> full desktop switch since I needed a Windows system for corporate
>>>> compatibility. Then I got a mac-mini to experiment with iPad Mobile Device
>>>> Management, and found it easier to get Latex working on it than on Windows
>>>> (for processing Pillar output), and now I find myself using it for Pharo
>>>> more every day, and my Windows box is starting to be neglected (except I
>>>> still need to migrate my old Thunderbird email archive).
>>>> However success in the corporate world still hinges a lot on Windows
>>>> compatibility. I will still have a go at updating PharoLauncher Installer
>>>> to avoid this problem.
>>>> cheers, Ben
>>>> P.S. @Tim, Your alternate-VM feature sound interesting.  I'll check it
>>>> out.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20140904/1cc1f0f3/attachment-0001.htm

More information about the Vm-dev mailing list