Ok, so we found the bug:

The working directory of a process is the directory from where we started the process. That is, the directory from where we launched the VM with the image.

Then, when we create a file without specifying a directory (that is, in a relative way), that file will be created in the working directory.

However, FileSystem has two problems
��1) it believes that the workingDirectory is where the image *is* and not where it was open. (Check FileSystem workingDirectory).
��2) if you try to use a relative file name FileSystem will for you the working directory he believes instead of letting the primitive do his job. (Just open your image from another directory and do 'asd.txt' asFileReference fullName).

So the fix to the test was: do not mix FileSystem with the low level File API.

I'll open a new thread discussing about the working directory.
Guille

El mar., 25 de ago. de 2015 a la(s) 7:22 p. m., Ben Coman <btc@openinworld.com> escribi��:
On Tue, Aug 25, 2015 at 11:30 PM, Guillermo Polito
<guillermopolito@gmail.com> wrote:
> Hi,
>
> We have an issue that is platform dependent (file-related):
>
> https://pharo.fogbugz.com/f/cases/15820/Better-File-API
>
> Now, we tested with Nicolai in Windows, Mac and Linux and we had all tests
> green. However, the monkey does not seem to want to be green.
>
> - Would anyone have an idea of what should be disturbing the monkey?

No ideas, except if you can't isolate it, maybe its possible to SSH
into the CI server, map VNC ports back to your local machine and debug
the image on the CI server.

cheers -ben

> - Can people in different linuxes/unixes test the slice just to make sure we
> are on the right path? (that is, load the slice and run the tests in the
> File package).
>
> Thanks a lot,
> Guille