Skip to content

reg-tests-1.R failure with unstable

6 messages · Hiroyuki Kawakatsu, Peter Dalgaard, Brian Ripley

Original
Hiroyuki Kawakatsu
# 
Hi,

I am getting an error from one of the test files
tests/reg-tests-1.R using the unstable version (r50179).
(i've learned my lessons; this is a clean build.) The tail
of reg-tests-1.Rout.fail is

Loading required package: myTst
building package pkgA ...
installing package pkgA using file pkgA_1.0.tar.gz ...
Error in as.octmode(mode) : invalid digits
Error in install.packages(r, lib = "myLib", repos = NULL, type = "source") :
  (converted from warning) installation of package 'pkgA_1.0.tar.gz'
had non-zero exit status
Execution halted

The error from as.octmode() appears to be coming from R CMD
INSTALL. If I unpack pkgA_1.0.tar.gz, 'R CMD INSTALL pkgA'
from the source tree works fine. However, 'R CMD INSTALL
 pkgA_1.0.tar.gz' returns the error. I am wondering whether
this is specific to my OS (FreeBSD).  Any pointers for
debugging would be appreciated.

h.
1 day later
Hiroyuki Kawakatsu
#
On Fri, Oct 23, 2009, Hiroyuki Kawakatsu wrote:
[...]

I think I have tracked this down to the following line in utils:::untar2()
        mode <- rawToChar(block[101:107])
mode contains a trailing space as in "000755 " which causes the invalid
digits error in as.octmode(). If I change the line to
        mode <- rawToChar(block[101:106])
untar2("pkgA_1.0.tar.gz") unpacks the test package but I, of course,
do not know whether this is a general fix.

Am I the only one seeing this problem (FreeBSD 9.0-CURRENT)?

h.
Peter Dalgaard
#
Hiroyuki Kawakatsu wrote:
But where does the as.octmode come from?? Conversions inside untar2 
appear to be using getOct which explicitly handles spaces.

The current SVN does run reg-tests-1.R for me. (It breaks on 
reg-tests-3.R, but that's a different issue.)
Hiroyuki Kawakatsu
#
On Sun, Oct 25, 2009 at 10:32 AM, Peter Dalgaard wrote:
[...]
from Sys.chmod(name, mode) further down in untar2().
but 'mode' is never touched between the assignment and the
call in Sys.chmod().
hmmm. I still don't understand what might be specific to my OS.

h.
Brian Ripley
#
On Sun, 25 Oct 2009, Hiroyuki Kawakatsu wrote:

            

      
      
      
    

        
Seems this is a bug in the tar program on your OS: this should be 
'0000755(nul)' in the 8 bytes 101:108. And that's in every account of 
the tar format I have found, including the former POSIX standard.

(Note to Peter D: we don't use getOct for this one, as it is not a 
field that is allowed to be space-padded.)

I guess we need to work around this ... to a large extent we have got 
away with using tar format in the past because everyone was using GNU 
tar, but others are coming into use.

[A quick check confirms that bsdtar from the libarchive project does 
this, as used by Snow Leopard and AFAIK FreeBSD >= 8.  So I can 
reproduce it.]

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Brian Ripley
    

    

      
      #
    

  


  

      
I have committed a workaround that works with bsdtar under Snow 
Leopard (Mac OS 10.6) for me.

We have seen rather too many problems with incompatibility of tar 
formats recently (and it is documented to be ASCII only and has 
restrictions to 100 bytes for file paths), so have alternatives under 
consideration.

        
On Sun, 25 Oct 2009, Prof Brian Ripley wrote: