Edit detail for #302 Cannot rename the file erlib to NRLIB revision 1 of 3

changed:
-
Since the upgrade of the version of Axiom on AxiomWiki 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":http://lists.nongnu.org/archive/cgi-bin/namazu.cgi?query=erlib&submit=Search%21&idxname=axiom-developer&max=10&result=normal&sort=date%3Alate
on the axiom-developer email list.




From root Wed Jul 5 12:57:29 -0500 2006
From: root
Date: Wed, 05 Jul 2006 12:57:29 -0500
Subject: (new)
Message-ID: <200607051750.k65HoAC17672@localhost.localdomain>
In-Reply-To: <20060705122403-0500@wiki.axiom-developer.org>
	(mathaction-bounces@axiom-developer.org)

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


t


From CammMaguire Thu Jul 13 12:18:27 -0500 2006
From: Camm Maguire
Date: Thu, 13 Jul 2006 12:18:27 -0500
Subject: (new)
Message-ID: <54fyh55spw.fsf@intech19.enhanced.com>
In-Reply-To: <200607051750.k65HoAC17672@localhost.localdomain>

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 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


From BillPage Wed Aug 30 18:11:22 -0500 2006
From: Bill Page
Date: Wed, 30 Aug 2006 18:11:22 -0500
Subject: new version of Axiom on MathAction
Message-ID: <20060830181122-0500@wiki.axiom-developer.org>

Status: open => testing 


From BillPage Wed Aug 30 18:23:33 -0500 2006
From: Bill Page
Date: Wed, 30 Aug 2006 18:23:33 -0500
Subject: Re: new version of Axiom on MathAction
Message-ID: <20060830182333-0500@wiki.axiom-developer.org>

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
(AxiomWiki and AxiomPortal). Please let me know if you see any
problems related to this change on these web sites.

Thanks.

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

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

  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

  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))