Failed to delete temporary file .eunit/xxx

Garrett Smith g at rre.tt
Thu Jul 21 16:42:54 EDT 2011


On Thu, Jul 21, 2011 at 12:01 PM, Garrett Smith <g at rre.tt> wrote:
> On Thu, Jul 21, 2011 at 11:52 AM, Garrett Smith <g at rre.tt> wrote:
>> On Thu, Jul 21, 2011 at 11:18 AM, Tuncer Ayaz <tuncer.ayaz at gmail.com> wrote:
>>> On Thu, Jul 21, 2011 at 4:53 PM, Garrett Smith wrote:
>>>> I'm getting this error every time I run rebar eunit after changing
>>>> this test.
>>>
>>> 1) compile:file/2 generated and saved beam code to the temporary
>>> file .eunit/tm_task_tests.bea#.
>>> 2) Then it failed to rename the temp file to .eunit/tm_task_tests.beam.
>>> 3) After that it failed to delete the temp file during cleanup.
>>>
>>> Are you using Rusty's sync or Mochi's reloader module?
>>
>> Neither.
>>
>> The error is "no such file or directory", which suggests the file
>> isn't there at the time of the move operations.
>>
>> I can recreate this consistently after making any change to any of the
>> test files.
>>
>> I didn't see this behavior initially however. I'm not sure at what
>> point this crept in. I see this the current git master rebar as well
>> as with 20101010_193118.
>>
>> IIRC, rebar compiles things in parallel. Could this be a sync issue
>> where someone's trying to rename/move the compiled files before the
>> file system sees them?
>
> This does appear to subtly related to the OS and file system.
>
> I opened a new terminal and could not initially recreate this in that
> window. Then the problem returned and remained consistently. There's
> no material differences in the env between the two terminals.
>
> If someone happens to know the module+line number of the code in
> question, I can investigate further.
>

This was a result of a couple things:

- I have an "examples" dir that contains some symlinks to files in
"test" - the examples dir is included in the
- rebar compiles "test" files and the main program files in
concurrently running processes

So the same modules are compiled as "test" and as non-test, at the same time.

I need to reconsider the rationale of symlinking source files, but
that aside, if two threads are accessing the file system, esp a common
set of files, they should probably be coordinated.

A simple work around for me is to use -j to set the workers to 1. But
I'll think about getting rid of the links for good measure :)

Thanks Tuncer for helping me work through this!

Garrett



More information about the rebar mailing list