Re: [Rd] package file permissions problem R 3.0.0/Windows OS

2013-04-15 Thread John Fox
Dear Brian,

On Mon, 15 Apr 2013 06:56:26 +0100
 Prof Brian Ripley  wrote:
> POSIX-style execute permission isn't a Windows concept, so it was fortuitous 
> this ever worked.  One possibility is that Cygwin was involved, and a Cygwin 
> emulation got set when tar unpacked the file and converted back to the tar 
> representation when Cygwin tar produced the tarball. (The tar in Rtools is a 
> fixed version of Cygwin tar, fixed to use Windows file paths.)
> 

Recall that the problem was first detected when I submitted to CRAN a new 
version of the sem package that I built on one of my Windows systems. I'm 
guessing that you unpacked that on a Linux system. Perhaps I misunderstand the 
point, but if the problem is in unpacking, then shouldn't I see it when the 
package is built on R 2.15.2 (not 2.5.2 -- sorry, my typo)?

> What are those screen shots of?

7zip, which I use on Windows to manage file archives.

> 
> R 2.5.2 was a very long time ago.  A recent change is

Indeed. Again, that is my unfortunate typo -- I used 2.15.2. I wanted to 
confirm that I can build packages with the correct permissions on my Windows 
systems using an older (but recent) version of R.

> 
>  • R CMD build by default uses the internal method of tar() to
>prepare the tarball.  This is more likely to produce a tarball
>compatible with R CMD INSTALL and R CMD check: an external tar
>program, including options, can be specified _via_ the
>environment variable R_BUILD_TAR.
> 

I saw that but didn't understand its import. That makes sense of a difference 
between R 2.15.2 and 3.0.0, though I'm not sure why this change would introduce 
a problem with the permissions.

> Can you try using an external tar?  (Using the internal tar on Windows was 
> first trialled in 2.15.3.)
> 

Yes, when I "set R_BUILD_TAR=tar" on my Windows 8 system, the tarball for the 
package is built with the correct permissions under R 3.0.0. The tar should be 
found in the Rtools\bin directory, which is first on my path. I don't have 
Cygwin installed on this machine independently of Rtools.

What's curious to me is that I'm seeing the problem on two different Windows 
system but, AFAIK, no one else has experienced a similar problem.

Thanks for your help,
 John

> 
> On 14/04/2013 22:17, John Fox wrote:
> > Dear list members,
> >
> > I'm experiencing a file permissions problem with a package built under
> > Windows with R 3.0.0. I've encountered the problem on two Windows computers,
> > one running Windows 7 and the other Windows 8, and both when I build the
> > package under RStudio or directly in a Windows console via "R CMD build".
> >
> > In particular, the cleanup file for the package, which as I understand it
> > should have permissions set at rwx-r-r, instead has permissions rw-rw-rw.
> > I've attached two .png screen shots showing how the permissions are set when
> > the package is built under R 2.5.2 and R 3.0.0.
> >
> > I think that my two Windows systems are reasonably vanilla. Here are the
> > system and session info from R 3.0.0 run from a Windows console:
> >
> >> Sys.info()
> >   sysname  release
> > "Windows"  "7 x64"
> >   version nodename
> > "build 7601, Service Pack 1"  "JOHN-DELL-XPS"
> >   machinelogin
> > "x86"   "User"
> >  user   effective_user
> >"User"   "User"
> >
> >> sessionInfo()
> > R version 3.0.0 (2013-04-03)
> > Platform: i386-w64-mingw32/i386 (32-bit)
> >
> > locale:
> > [1] LC_COLLATE=English_United States.1252
> > [2] LC_CTYPE=English_United States.1252
> > [3] LC_MONETARY=English_United States.1252
> > [4] LC_NUMERIC=C
> > [5] LC_TIME=English_United States.1252
> >
> > attached base packages:
> > [1] stats graphics  grDevices utils datasets  methods   base
> >
> > I have the latest Rtools30 installed and on my path:
> >
> >> Sys.which("tar.exe")
> > tar.exe
> > "c:\\Rtools\\bin\\tar.exe"
> >
> > Is this a general problem or is it possible that there's something about my
> > Windows configurations that's causing it?
> >
> > Any information would be appreciated.
> >
> > John
> >
> > ---
> > John Fox
> > Senator McMaster Professor of Social Statistics
> > Department of Sociology
> > McMaster University
> > Hamilton, Ontario, Canada
> >
> >
> >
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
> 
> 
> -- 
> Brian D. Ripley,  rip...@stats.ox.ac.uk
> Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
> University of Oxford, Tel:  +44 1865 272861 (self)
> 1 South Parks Road,   

Re: [Rd] windows compile R from source, where do I put the Tcl directory?

2013-04-15 Thread Andre Mikulec
>Message: 2
>Date: Sun, 14 Apr 2013 07:14:28 -0400
>From: Duncan Murdoch 
>To: Andre Mikulec 
>Cc: "r-devel@r-project.org" 
>Subject: Re: [Rd] windows compile R from source, where do I put the
>Tcl directory?
>Message-ID: <516a8f94.1040...@gmail.com>
>Content-Type: text/plain; charset=KOI8-R; format=flowed
>
>On 13-04-13 10:03 PM, Andre Mikulec wrote:
 Prof Brian Ripley ripley at stats.ox.ac.uk
 Thu Apr 11 13:32:02 CEST 2013
 Previous message: [Rd] windows compile R from source, where do I put the 
 Tcl directory?
 Next message: [Rd] Trying to make DEBUG=T a debug version of R
 Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
 On 11/04/2013 00:27, Andre Mikulec wrote:
> Hi,
>
> I am trying to compile R from source on Windows.
> I am following the instructions here
>
> 3.1 Building from source
> 3 Installing R under Windows
> file:///F:/ProgramFiles/R/R-2.15.3/doc/manual/R-admin.html
>
> It only says,
>
> "
> The Tcl/Tk support files are contained in Rtools30.exe and
> available as .zips from http://www.stats.ox.ac.uk/pub/Rtools.
> Please make sure you install the right version: there is a 32-bit
> version and a 64-bit version.
> "
>
> Anyways,
> I collected the support files from here.
> http://www.stats.ox.ac.uk/pub/Rtools/R_Tcl_8-5-8.zip
>
> The instructions do not say "where to put my Tcl folder."

 Rtools30.exe does this for you. But you put it at the top level in the
 sources.

> So I just guessed, based on ( include, doc, and bin are parallel 
> directories )
> in F:\ProgramFiles\R\R-2.15.3\Tcl
>
> I guessed ( and guessed wrong ) ...
> M:\YDrive\All_Economics\eclipse_workspace\R-2.15.3\src\Tcl

 Why in src? It is a binary distriution.

> When Try to compile with
>
> M:\YDrive\All_Economics\eclipse_workspace\R-2.15.3\src\gnuwin32>make all 
> recommended
>
> I eventually get ...
>
> "tcltk.h:23:17: fatal error: tcl.h: No such file or directory"
>
> in the message
>
> building package 'tcltk'
> making init.d from init.c
> making tcltk.d from tcltk.c
> making tcltk_win.d from tcltk_win.c
> gcc -I"../../../../include" -DNDEBUG -I "../../../../Tcl"/include -DWin32 
> -O3 -Wall -gdwarf-2 -std=gnu99 -c init.c -o init.o
> In file included from init.c:22:0:
> tcltk.h:23:17: fatal error: tcl.h: No such file or directory
> compilation terminated.
> make[4]: *** [init.o] Error 1
> make[3]: *** [mksrc-win2] Error 1
> make[2]: *** [all] Error 2
> make[1]: *** [R] Error 1
> make: *** [all] Error 2
>
> Please, help.
>
> Thank you.
> Andre Mikulec
> Andre_Mikulec at Hotmail.com
> __
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>


 --
 Brian D. Ripley, ripley at stats.ox.ac.uk
 Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
 University of Oxford, Tel: +44 1865 272861 (self)
 1 South Parks Road, +44 1865 272866 (PA)
 Oxford OX1 3TG, UK Fax: +44 1865 272595
>>
>>
>> "Why in src? It is a binary distriution."
>>
>> Yes, I have the binary distribution ( but it is not found in RTools )
>>
>> "
>> Rtools30.exe does this for you. But you put it at the top level in the
>> sources.
>> "
>> Maybe I do not know where the 'top level' is located.
>>
>> Please, help.
>>
>> I used "tree /f" and search for
>> "tk" and "tcl" files in my
>>
>> F:\RTools folder
>
>The Tcl/Tk files are in Rtools.exe, and are installed to the top level 
>of the R directory tree, unless you chose (when running Rtools.exe) not 
>to install them. They are not installed to the Rtools directory tree.
>
>Duncan Murdoch
>
 
 
I have spent 3 attempts to compile R and end up at the very same spot.
 
 
  "tcltk.h:23:17: fatal error: tcl.h: No such file or directory"
 
 
RTools.exe does not install a tcl.h file.  It is not there. I looked and looked 
and looked.
 

R-2.15.3 source code does not have a tcl.h file. I looked and looked and looked.
 

R_Tcl_8-5-8.zip does have a tcl.h file.
 
 

2. My folder contents are the following.
 
 
  1. RTools folder, 
  2. R-2.15.3 source code folder
  3. Tcl folder ( from R_Tcl_8-5-8.zip ) 
 
 
Their locations are the following.
 
 
  1. F:\RTools
  2. M:\YDrive\All_Economics\eclipse_workspace\R\R-2.15.3
  3. M:\YDrive\All_Economics\eclipse_workspace\Tcl 
 
 
Where do I stick the "Tcl" folder?
 

What is a "top level of the R directory tree?" Where is it?
 
 
Thank you,
Andre Mikulec
andre_miku...@hotmail.com

 
 
 
 
  
[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


Re: [Rd] windows compile R from source, where do I put the Tcl directory?

2013-04-15 Thread Duncan Murdoch

On 13-04-15 1:11 PM, Andre Mikulec wrote:

Message: 2
Date: Sun, 14 Apr 2013 07:14:28 -0400
From: Duncan Murdoch 
To: Andre Mikulec 
Cc: "r-devel@r-project.org" 
Subject: Re: [Rd] windows compile R from source, where do I put the
Tcl directory?
Message-ID: <516a8f94.1040...@gmail.com>
Content-Type: text/plain; charset=KOI8-R; format=flowed

On 13-04-13 10:03 PM, Andre Mikulec wrote:

Prof Brian Ripley ripley at stats.ox.ac.uk
Thu Apr 11 13:32:02 CEST 2013
Previous message: [Rd] windows compile R from source, where do I put the Tcl 
directory?
Next message: [Rd] Trying to make DEBUG=T a debug version of R
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 11/04/2013 00:27, Andre Mikulec wrote:

Hi,

I am trying to compile R from source on Windows.
I am following the instructions here

3.1 Building from source
3 Installing R under Windows
file:///F:/ProgramFiles/R/R-2.15.3/doc/manual/R-admin.html

It only says,

"
The Tcl/Tk support files are contained in Rtools30.exe and
available as .zips from http://www.stats.ox.ac.uk/pub/Rtools.
Please make sure you install the right version: there is a 32-bit
version and a 64-bit version.
"

Anyways,
I collected the support files from here.
http://www.stats.ox.ac.uk/pub/Rtools/R_Tcl_8-5-8.zip

The instructions do not say "where to put my Tcl folder."


Rtools30.exe does this for you. But you put it at the top level in the
sources.


So I just guessed, based on ( include, doc, and bin are parallel directories )
in F:\ProgramFiles\R\R-2.15.3\Tcl

I guessed ( and guessed wrong ) ...
M:\YDrive\All_Economics\eclipse_workspace\R-2.15.3\src\Tcl


Why in src? It is a binary distriution.


When Try to compile with

M:\YDrive\All_Economics\eclipse_workspace\R-2.15.3\src\gnuwin32>make all 
recommended

I eventually get ...

"tcltk.h:23:17: fatal error: tcl.h: No such file or directory"

in the message

building package 'tcltk'
making init.d from init.c
making tcltk.d from tcltk.c
making tcltk_win.d from tcltk_win.c
gcc -I"../../../../include" -DNDEBUG -I "../../../../Tcl"/include -DWin32 -O3 
-Wall -gdwarf-2 -std=gnu99 -c init.c -o init.o
In file included from init.c:22:0:
tcltk.h:23:17: fatal error: tcl.h: No such file or directory
compilation terminated.
make[4]: *** [init.o] Error 1
make[3]: *** [mksrc-win2] Error 1
make[2]: *** [all] Error 2
make[1]: *** [R] Error 1
make: *** [all] Error 2

Please, help.

Thank you.
Andre Mikulec
Andre_Mikulec at Hotmail.com
__
R-devel at r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel




--
Brian D. Ripley, ripley at stats.ox.ac.uk
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UK Fax: +44 1865 272595



"Why in src? It is a binary distriution."

Yes, I have the binary distribution ( but it is not found in RTools )

"
Rtools30.exe does this for you. But you put it at the top level in the
sources.
"
Maybe I do not know where the 'top level' is located.

Please, help.

I used "tree /f" and search for
"tk" and "tcl" files in my

F:\RTools folder


The Tcl/Tk files are in Rtools.exe, and are installed to the top level
of the R directory tree, unless you chose (when running Rtools.exe) not
to install them. They are not installed to the Rtools directory tree.

Duncan Murdoch




I have spent 3 attempts to compile R and end up at the very same spot.


   "tcltk.h:23:17: fatal error: tcl.h: No such file or directory"


RTools.exe does not install a tcl.h file.  It is not there. I looked and looked 
and looked.


That's because you told it not to.  Run it again, and select one or both 
of the "Extras" under custom installation, or "full installation".





R-2.15.3 source code does not have a tcl.h file. I looked and looked and looked.


R_Tcl_8-5-8.zip does have a tcl.h file.



2. My folder contents are the following.


   1. RTools folder,
   2. R-2.15.3 source code folder
   3. Tcl folder ( from R_Tcl_8-5-8.zip )


Their locations are the following.


   1. F:\RTools
   2. M:\YDrive\All_Economics\eclipse_workspace\R\R-2.15.3
   3. M:\YDrive\All_Economics\eclipse_workspace\Tcl


Where do I stick the "Tcl" folder?


In M:\YDrive\All_Economics\eclipse_workspace\R\R-2.15.3.



What is a "top level of the R directory tree?" Where is it?


M:\YDrive\All_Economics\eclipse_workspace\R\R-2.15.3

By the way, I don't think it will be a problem, but that path is getting 
kind of long, and Windows has a 256 character limit on path length.


Duncan Murdoch




Thank you,
Andre Mikulec
andre_miku...@hotmail.com






[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel



__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-de

Re: [Rd] package file permissions problem R 3.0.0/Windows OS

2013-04-15 Thread Prof Brian Ripley

On 15/04/2013 14:11, John Fox wrote:

Dear Brian,

On Mon, 15 Apr 2013 06:56:26 +0100
  Prof Brian Ripley  wrote:

POSIX-style execute permission isn't a Windows concept, so it was fortuitous 
this ever worked.  One possibility is that Cygwin was involved, and a Cygwin 
emulation got set when tar unpacked the file and converted back to the tar 
representation when Cygwin tar produced the tarball. (The tar in Rtools is a 
fixed version of Cygwin tar, fixed to use Windows file paths.)



Recall that the problem was first detected when I submitted to CRAN
a

new version of the sem package that I built on one of my Windows
systems. I'm guessing that you unpacked that on a Linux system. Perhaps
I misunderstand the point, but if the problem is in unpacking, then
shouldn't I see it when the package is built on R 2.15.2 (not 2.5.2 --
sorry, my typo)?

The puzzle is how you got execute permissions recorded for files on your 
Windows system.  They are not part of the Windows file system: Cygwin 
uses ACLs to emulate them.  Once the ACLs are there, a Cygwin-based tar 
will put them as permissions into the tarball.  But a native Windows 
tool would not (it might or might not capture the ACLs using a tar 
extension, but those would be ignored by most unpacking tools on a 
Unix-alike).


The issue is not really Windows: if you use a FAT file system on a 
Unix-alike you have the same problem -- this is why SMB mounts at least 
did not work on OS X for building R (and much else), and you need to be 
careful transferring directories via USB sticks (which are usually 
FAT-formatted).  That route usually makes the opposite compromise: to 
assume everything is executable.



What are those screen shots of?


7zip, which I use on Windows to manage file archives.


Ah, so that's a listing of the .tar.gz, a graphical form of tar -tvf.


R 2.5.2 was a very long time ago.  A recent change is


Indeed. Again, that is my unfortunate typo -- I used 2.15.2. I wanted to 
confirm that I can build packages with the correct permissions on my Windows 
systems using an older (but recent) version of R.



  • R CMD build by default uses the internal method of tar() to
prepare the tarball.  This is more likely to produce a tarball
compatible with R CMD INSTALL and R CMD check: an external tar
program, including options, can be specified _via_ the
environment variable R_BUILD_TAR.



I saw that but didn't understand its import. That makes sense of a difference 
between R 2.15.2 and 3.0.0, though I'm not sure why this change would introduce 
a problem with the permissions.


Can you try using an external tar?  (Using the internal tar on Windows was 
first trialled in 2.15.3.)



Yes, when I "set R_BUILD_TAR=tar" on my Windows 8 system, the tarball for the 
package is built with the correct permissions under R 3.0.0. The tar should be found in 
the Rtools\bin directory, which is first on my path. I don't have Cygwin installed on 
this machine independently of Rtools.

What's curious to me is that I'm seeing the problem on two different Windows 
system but, AFAIK, no one else has experienced a similar problem.


Very few Windows users will ever get a file that appears to 'tar' to 
have execute permissions.  For example, svn checkouts on Windows lose 
execute permissions, something which has caught me for time to time over 
the years.



Thanks for your help,
  John



On 14/04/2013 22:17, John Fox wrote:

Dear list members,

I'm experiencing a file permissions problem with a package built under
Windows with R 3.0.0. I've encountered the problem on two Windows computers,
one running Windows 7 and the other Windows 8, and both when I build the
package under RStudio or directly in a Windows console via "R CMD build".

In particular, the cleanup file for the package, which as I understand it
should have permissions set at rwx-r-r, instead has permissions rw-rw-rw.
I've attached two .png screen shots showing how the permissions are set when
the package is built under R 2.5.2 and R 3.0.0.

I think that my two Windows systems are reasonably vanilla. Here are the
system and session info from R 3.0.0 run from a Windows console:


Sys.info()

   sysname  release
 "Windows"  "7 x64"
   version nodename
"build 7601, Service Pack 1"  "JOHN-DELL-XPS"
   machinelogin
 "x86"   "User"
  user   effective_user
"User"   "User"


sessionInfo()

R version 3.0.0 (2013-04-03)
Platform: i386-w64-mingw32/i386 (32-bit)

locale:
[1] LC_COLLATE=English_United States.1252
[2] LC_CTYPE=English_United States.1252
[3] LC_MONETARY=English_United States.1252
[4] LC_NUMERIC=C
[5] LC_TIME=English_United States.1252

attached base packages:
[1] stats   

Re: [Rd] package file permissions problem R 3.0.0/Windows OS

2013-04-15 Thread Paul Gilbert



On 13-04-15 03:19 PM, Prof Brian Ripley wrote:

On 15/04/2013 14:11, John Fox wrote:

Dear Brian,

On Mon, 15 Apr 2013 06:56:26 +0100
  Prof Brian Ripley  wrote:

POSIX-style execute permission isn't a Windows concept, so it was
fortuitous this ever worked.  One possibility is that Cygwin was
involved, and a Cygwin emulation got set when tar unpacked the file
and converted back to the tar representation when Cygwin tar produced
the tarball. (The tar in Rtools is a fixed version of Cygwin tar,
fixed to use Windows file paths.)



Recall that the problem was first detected when I submitted to CRAN
a

new version of the sem package that I built on one of my Windows
systems. I'm guessing that you unpacked that on a Linux system. Perhaps
I misunderstand the point, but if the problem is in unpacking, then
shouldn't I see it when the package is built on R 2.15.2 (not 2.5.2 --
sorry, my typo)?

The puzzle is how you got execute permissions recorded for files on your
Windows system.  They are not part of the Windows file system: Cygwin
uses ACLs to emulate them.  Once the ACLs are there, a Cygwin-based tar
will put them as permissions into the tarball.  But a native Windows
tool would not (it might or might not capture the ACLs using a tar
extension, but those would be ignored by most unpacking tools on a
Unix-alike).

The issue is not really Windows: if you use a FAT file system on a
Unix-alike you have the same problem -- this is why SMB mounts at least
did not work on OS X for building R (and much else), and you need to be
careful transferring directories via USB sticks (which are usually
FAT-formatted).  That route usually makes the opposite compromise: to
assume everything is executable.


What are those screen shots of?


7zip, which I use on Windows to manage file archives.


Ah, so that's a listing of the .tar.gz, a graphical form of tar -tvf.


R 2.5.2 was a very long time ago.  A recent change is


Indeed. Again, that is my unfortunate typo -- I used 2.15.2. I wanted
to confirm that I can build packages with the correct permissions on
my Windows systems using an older (but recent) version of R.



  • R CMD build by default uses the internal method of tar() to
prepare the tarball.  This is more likely to produce a tarball
compatible with R CMD INSTALL and R CMD check: an external tar
program, including options, can be specified _via_ the
environment variable R_BUILD_TAR.



I saw that but didn't understand its import. That makes sense of a
difference between R 2.15.2 and 3.0.0, though I'm not sure why this
change would introduce a problem with the permissions.


Can you try using an external tar?  (Using the internal tar on
Windows was first trialled in 2.15.3.)



Yes, when I "set R_BUILD_TAR=tar" on my Windows 8 system, the tarball
for the package is built with the correct permissions under R 3.0.0.
The tar should be found in the Rtools\bin directory, which is first on
my path. I don't have Cygwin installed on this machine independently
of Rtools.

What's curious to me is that I'm seeing the problem on two different
Windows system but, AFAIK, no one else has experienced a similar problem.


Very few Windows users will ever get a file that appears to 'tar' to
have execute permissions.  For example, svn checkouts on Windows lose
execute permissions, something which has caught me for time to time over
the years.


I am just having the opposite problem, sliksvn is adding x permission on 
checkout, to some but not all files. Not sure why and I don't want it 
to, so would be happy to hear suggestions.


Paul




Thanks for your help,
  John



On 14/04/2013 22:17, John Fox wrote:

Dear list members,

I'm experiencing a file permissions problem with a package built under
Windows with R 3.0.0. I've encountered the problem on two Windows
computers,
one running Windows 7 and the other Windows 8, and both when I build
the
package under RStudio or directly in a Windows console via "R CMD
build".

In particular, the cleanup file for the package, which as I
understand it
should have permissions set at rwx-r-r, instead has permissions
rw-rw-rw.
I've attached two .png screen shots showing how the permissions are
set when
the package is built under R 2.5.2 and R 3.0.0.

I think that my two Windows systems are reasonably vanilla. Here are
the
system and session info from R 3.0.0 run from a Windows console:


Sys.info()

   sysname  release
 "Windows"  "7 x64"
   version nodename
"build 7601, Service Pack 1"  "JOHN-DELL-XPS"
   machinelogin
 "x86"   "User"
  user   effective_user
"User"   "User"


sessionInfo()

R version 3.0.0 (2013-04-03)
Platform: i386-w64-mingw32/i386 (32-bit)

locale:

Re: [Rd] package file permissions problem R 3.0.0/Windows OS

2013-04-15 Thread John Fox
Dear Brian,

I hope that I can clarify the issue and not confuse it further. I apologize if 
I was less than clear.

I originally built the tarball for the sem package on my Windows 7 system using 
"R CMD build" via RStudio with R 3.0.0. Both my Windows 7 system and the 
Windows 8 system that I subsequently also used to build the package tarball use 
the NTFS file system. Of course, these are Windows file systems and don't use 
the Unix permission scheme, but there are apparently permissions recorded in 
the tarball, and they caused problems for you when I submitted the package to 
CRAN. The permissions are visible when I look inside the tarball, e.g., with 
7zip. 

When I rebuilt the package using "R CMD build" with R 2.15.2 (as opposed to 
3.0.0) on both of these Windows systems, the permissions inside the tarball 
were correct.

I never built the package on my Linux system, although I did try building it on 
my Mac. I obtained correct permissions inside the tarball when I did, which 
isn't surprising. 

If it's the case that package tarballs built under Windows don't have execute 
permissions set where these are needed (as for cleanup), won't you have the 
same problem when such tarballs are submitted to CRAN that you had with the sem 
package?

Also, I'm still not clear why the execute permissions were set properly when I 
created the tarball having set R_BUILD_TAR=tar or using R 2.15.2.

To reiterate, if this issue is unique to me, I can certainly work around it. I 
know that it's hard to diagnose this kind of problem long-distance via email.

Best,
 John

On Mon, 15 Apr 2013 20:19:21 +0100
 Prof Brian Ripley  wrote:
> On 15/04/2013 14:11, John Fox wrote:
> > Dear Brian,
> >
> > On Mon, 15 Apr 2013 06:56:26 +0100
> >   Prof Brian Ripley  wrote:
> >> POSIX-style execute permission isn't a Windows concept, so it was 
> >> fortuitous this ever worked.  One possibility is that Cygwin was involved, 
> >> and a Cygwin emulation got set when tar unpacked the file and converted 
> >> back to the tar representation when Cygwin tar produced the tarball. (The 
> >> tar in Rtools is a fixed version of Cygwin tar, fixed to use Windows file 
> >> paths.)
> >>
> >
> > Recall that the problem was first detected when I submitted to CRAN
> > a
> new version of the sem package that I built on one of my Windows
> systems. I'm guessing that you unpacked that on a Linux system. Perhaps
> I misunderstand the point, but if the problem is in unpacking, then
> shouldn't I see it when the package is built on R 2.15.2 (not 2.5.2 --
> sorry, my typo)?
> 
> The puzzle is how you got execute permissions recorded for files on your 
> Windows system.  They are not part of the Windows file system: Cygwin uses 
> ACLs to emulate them.  Once the ACLs are there, a Cygwin-based tar will put 
> them as permissions into the tarball.  But a native Windows tool would not 
> (it might or might not capture the ACLs using a tar extension, but those 
> would be ignored by most unpacking tools on a Unix-alike).
> 
> The issue is not really Windows: if you use a FAT file system on a Unix-alike 
> you have the same problem -- this is why SMB mounts at least did not work on 
> OS X for building R (and much else), and you need to be careful transferring 
> directories via USB sticks (which are usually FAT-formatted).  That route 
> usually makes the opposite compromise: to assume everything is executable.
> 
> >> What are those screen shots of?
> >
> > 7zip, which I use on Windows to manage file archives.
> 
> Ah, so that's a listing of the .tar.gz, a graphical form of tar -tvf.
> 
> >> R 2.5.2 was a very long time ago.  A recent change is
> >
> > Indeed. Again, that is my unfortunate typo -- I used 2.15.2. I wanted to 
> > confirm that I can build packages with the correct permissions on my 
> > Windows systems using an older (but recent) version of R.
> >
> >>
> >>   • R CMD build by default uses the internal method of tar() to
> >> prepare the tarball.  This is more likely to produce a tarball
> >> compatible with R CMD INSTALL and R CMD check: an external tar
> >> program, including options, can be specified _via_ the
> >> environment variable R_BUILD_TAR.
> >>
> >
> > I saw that but didn't understand its import. That makes sense of a 
> > difference between R 2.15.2 and 3.0.0, though I'm not sure why this change 
> > would introduce a problem with the permissions.
> >
> >> Can you try using an external tar?  (Using the internal tar on Windows was 
> >> first trialled in 2.15.3.)
> >>
> >
> > Yes, when I "set R_BUILD_TAR=tar" on my Windows 8 system, the tarball for 
> > the package is built with the correct permissions under R 3.0.0. The tar 
> > should be found in the Rtools\bin directory, which is first on my path. I 
> > don't have Cygwin installed on this machine independently of Rtools.
> >
> > What's curious to me is that I'm seeing the problem on two different 
> > Windows system but, AFAIK, no one else h