[Ecls-list] What would be the cause of "Error when copying file from"?

[Pascal J. Bourguignon]

Juan Jose Garcia-Ripoll <juanjose.garciaripoll at googlemail.com> writes:

> On Thu, Jul 1, 2010 at 3:33 AM, Pascal J. Bourguignon <pjb at informatimago.com> wrote:
>
>     I get this error when asdf loading  :usocket.
>     [pjb at kuiper :0.0 site]$ ls -ld /tmp
>     drwxrwxrwt 9 root root 36864 Jul  1 03:18 /tmp/
>     What could be the cause?
>
> ECL has to have the ability to load the same FASL file multiple
> times. Furthermore, these files must be deletable as the user may
> wish to overwrite them at any time. None of these requirements works
> with an implementation that relies on the operating system to load
> binaries.  Some reasons are
>
> * Binary file write permissions may be disabled when the file is
>   loaded.
> * The operating system may refuse to load a binary file with the
>   same name as one that was already loaded.
> * If the file is overwritten, some operating systems still refuse to
>   load it again.
> ...
> The list is uncountable :-) After a lot of consideration the only
> solution I found is to perform a copy of each FASL file before
> LOADing it. Thus
>
> LOAD
> -> ecl_library_open
>  -> copy_object_file
>   -> si_copy_file
>  -> dlopen

I understand.

But I guess this concerns only MS-Windows, and not unix systems, where
we could have a simplier algorithm.  Or does this depend on the file
system?


> At some point your OS seems to be refusing _also_ that the FASL file
> be copied, which is kind of weird. I hope this will help you find
> out what is the problem -- here usocket loads just fine :-/

Yes, it's definitely mysterious.  I'm still searching...


Now that I think about it, perhaps I did something wrong.  I noticed a
lot of ecl "temporary" files in /tmp, and I removed them wholesale.
Perhaps I should wait to quit all ECL processes before cleaning up
/tmp?




>     Also, is this something of slime or of ECL not to print the whole
>     pathnames?  I've got *print-length* set to NIL, etc though...
>
> Probably Slime's debugger sets *print-length* or uses some custom printing format.

Of course, changing two elements of my environment at the same time
doesn't help.  Sorry for the occasional noise.


-- 
__Pascal Bourguignon__                     http://www.informatimago.com/