Nicolai Hess wrote:

2014-09-04 18:53 GMT+02:00 Ben Coman <btc@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
(http://www.gnu.org/software/libc/manual/html_node/Renaming-Files.html) results in an error
EXDEV�� 'Invalid cross-device link'

if the two file names newname and oldname are on different file systems.

Thanks Nicolas.�� So given that its similar across platforms and reflects the system-level semantics, probably we should not change its behaviour, and handle this case at the PharoLauncher level.��

However it would be useful in Image to get something like an 'InvalidCrossVolume' exception.�� I'm not sure off-hand how to approach that.

cheers -ben

��

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

led.

[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@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@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@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@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.