Since the upgrade of the version of Axiom on FriCASWiki from the September 2006 release to the April 2006 release it is no longer possible to re-compile SPAD code without getting the error message:

   >> System error:
   Cannot rename the file #p"XPRIMARR.erlib" to #p"XPRIMARR.NRLIB".

See for example: SandBoxArrays

If I log on to the server and delete these two directories:

  rm -r /var/zope/var/LatexWiki/XPRIMARR.*

then the compile works fine. The access rights to the files should have allowed the rename:

  ls -l -d XPRIM*
  drwxr-xr-x    2 plone    plone        4096 Jul  5 12:07 XPRIMARR.erlib
  drwxr-xr-x    2 plone    plone        4096 Jul  5 12:01 XPRIMARR.NRLIB

Some internal file system behaviour has changed (maybe in GCL?) since the previous release.

This was previously reported on the axiom-developer email list.

this has got to be a GCL change because this was never a problem before and the code has not changed.

t

Greetings! This GCL code has not changed in ages either to my knowledge. On BSD systems, the rename C call is used, which can fail for the following reasons:

EACCES Write permission is denied for the directory containing oldpath or newpath, or, search permission is denied for one of the directories in the path prefix of oldpath or newpath, or oldpath is a directory and does not allow write permission (needed to update the .. entry). (See also path_resolution(2).)

EBUSY The rename fails because oldpath or newpath is a directory that is in use by some process (perhaps as current working direc- tory, or as root directory, or because it was open for reading) or is in use by the system (for example as mount point), while the system considers this an error. (Note that there is no requirement to return EBUSY in such cases -- there is nothing wrong with doing the rename anyway -- but it is allowed to return EBUSY if the system cannot otherwise handle such situa- tions.)

EFAULT oldpath or newpath points outside your accessible address space.

EINVAL The new pathname contained a path prefix of the old, or, more generally, an attempt was made to make a directory a subdirec- tory of itself.

EISDIR newpath is an existing directory, but oldpath is not a directory.

ELOOP Too many symbolic links were encountered in resolving oldpath or newpath.

EMLINK oldpath already has the maximum number of links to it, or it was a directory and the directory containing newpath has the max- imum number of links.

ENAMETOOLONG oldpath or newpath was too long.

ENOENT A directory component in oldpath or newpath does not exist or is a dangling symbolic link.

ENOMEM Insufficient kernel memory was available.

ENOSPC The device containing the file has no room for the new directory entry.

ENOTDIR A component used as a directory in oldpath or newpath is not, in fact, a directory. Or, oldpath is a directory, and newpath exists but is not a directory.

ENOTEMPTY or EEXIST newpath is a non-empty directory, i.e., contains entries other than "." and "..".

EPERM or EACCES The directory containing oldpath has the sticky bit (S_ISVTX) set and the process's effective user ID is neither the user ID of the file to be deleted nor that of the directory containing it, and the process is not privileged (Linux: does not have the CAP_FOWNER capability); or newpath is an existing file and the directory containing it has the sticky bit set and the pro- cess's effective user ID is neither the user ID of the file to be replaced nor that of the directory containing it, and the process is not privileged (Linux: does not have the CAP_FOWNER capability); or the filesystem containing pathname does not support renaming of the type requested.

EROFS The file is on a read-only filesystem.

EXDEV oldpath and newpath are not on the same mounted filesystem. (Linux permits a filesystem to be mounted at multiple points, but rename(2) does not work across different mount points, even if the same filesystem is mounted on both.)

from file.d:

#ifdef HAVE_RENAME if (rename(filename, newfilename) < 0) FEerror("Cannot rename the file ~S to ~S.", 2, vs_base[0], vs_base[1]); #else sprintf(command, "mv %s %s", filename, newfilename); system(command); #endif

Would be great to export errno for all such system calls.

Take care,

mathaction-bounces@axiom-developer.org (root) writes:

Changes http://wiki.axiom-developer.org/302CannotRenameTheFileErlibToNRLIB/diff -- this has got to be a GCL change because this was never a problem before and the code has not changed.

t

-- forwarded from msg200607051750.k65HoAC17672@localhost.localdomain">http://wiki.axiom-developer.org/302CannotRenameTheFileErlibToNRLIB#msg200607051750.k65HoAC17672@localhost.localdomain

-- Camm Maguire camm@enhanced.com ========================================================================== "The earth is but one country, and mankind its citizens." -- Baha'u'llah

Status: open => testing

In since GCL verison 2.6.7pre the lisp function probe-file returns nil for directories. This caused the delete-directory functioin to be skipped which then caused rename-file to fail.

I have patched the current Axiom Silver build.improvements branch src/interp/nlib.lisp.pamphlet file as follows:

  replaced '(probe-file filearg)' with '(directory (truename filearg))' in

  ;; ($ERASE filearg) -> 0 if succeeds else 1
  (defun $erase (&rest filearg)
    (setq filearg (make-full-namestring filearg))
    (if (directory (truename filearg))
  #+:CCL (delete-file filearg)
  #+:AKCL
        (if (library-file filearg)
            (delete-directory filearg)
            (delete-file filearg))
        1))

I built a new version of Axiom and installed in on MathAction (FriCASWiki and AxiomPortal?). Please let me know if you see any problems related to this change on these web sites.

Thanks.

Status: testing => closed