R devel - Aug 2004 - (PR#7163) Install packages does not work on Win2003 serv er

> -----Original Message-----
> From:	Uwe Ligges [SMTP:ligges@statistik.uni-dortmund.de]
> Sent:	Thursday, August 12, 2004 5:38 PM
> To:	Walke, Rainer
> Cc:	R-devel
> Subject:	Re: [Rd] (PR#7163) Install packages does not work on Win2003
> server
> 
> Walke, Rainer wrote:
> 
> > 	>a) It works for me.
> > 	>b) If it works for you on some Windows versions but not on
others,
> > why 
> > 	>do you think it is a bug in R?
> > 
> > 	It is the first of our application that shows this problem. At least
> > as far as I know.
> > 	The installation of R works without any problem, only the addition
> > of further packages does not. What is the difference between both
> > installation parts? Of course you may ask what is the difference
between
> > Windows NT and Windows XP as client system. And you may ask what is
the
> > difference between a Windows NT and a Windows 2003 file server?
> > 	Is R using a piece of code that Windows XP sends wrong to a Windows
> > 2003 file server?
> > 
> > 	>Quite probably something is not set up correctly either in your 
> > 	>configuration of Windows (permissions, quota, ...) or in the 
> > 	>configuration of R (do you have set another library path to
install
> > to)?
> > 
> > 	>Please tell us the way you tried to install the package.
> > 
> > 	>Uwe Ligges
> > 
> > 	What I did, was "Install packages from local zip files..."
> > interactivly.
> > 
> > 	Best,
> > 	Rainer Walke
> 
> 
	> Is the share form which R has been started mounted on a drive
letter or 
	> do you start via the UNC path?
	> Which package is it? Does it also happen for CRAN packages?
	> I guess any security setting either on the Server or the client
are 
	> blocking the installation. But it is really hard to guess what it
really 
	> is... You might want to ask your local IT stuff.

	> Uwe Ligges

	Thanks for your e-mail message. Yes, the share has been mounted on a
drive letter P.
	Unfortunately, it happens for all packages starting from abind...
	And it happens if I load a package directly from CRAN as well.
	Do you know which part of the R code creates this temporary file*
directories in the library subdirectory?

	Rainer Walke



+++++
This mail has been sent through the MPI for Demographic Rese...{{dropped}}

Walke, Rainer wrote:
> 
>>-----Original Message-----
>>From:	Uwe Ligges [SMTP:ligges@statistik.uni-dortmund.de]
>>Sent:	Thursday, August 12, 2004 5:38 PM
>>To:	Walke, Rainer
>>Cc:	R-devel
>>Subject:	Re: [Rd] (PR#7163) Install packages does not work on Win2003
>>server
>>
>>Walke, Rainer wrote:
>>
>>
>>>	>a) It works for me.
>>>	>b) If it works for you on some Windows versions but not on
others,
>>>why 
>>>	>do you think it is a bug in R?
>>>
>>>	It is the first of our application that shows this problem. At
least
>>>as far as I know.
>>>	The installation of R works without any problem, only the addition
>>>of further packages does not. What is the difference between both
>>>installation parts? Of course you may ask what is the difference
between
>>>Windows NT and Windows XP as client system. And you may ask what is
the
>>>difference between a Windows NT and a Windows 2003 file server?
>>>	Is R using a piece of code that Windows XP sends wrong to a Windows
>>>2003 file server?
>>>
>>>	>Quite probably something is not set up correctly either in your
>>>	>configuration of Windows (permissions, quota, ...) or in the 
>>>	>configuration of R (do you have set another library path to
install
>>>to)?
>>>
>>>	>Please tell us the way you tried to install the package.
>>>
>>>	>Uwe Ligges
>>>
>>>	What I did, was "Install packages from local zip
files..."
>>>interactivly.
>>>
>>>	Best,
>>>	Rainer Walke
>>
>>
> 	> Is the share form which R has been started mounted on a drive
> letter or 
> 	> do you start via the UNC path?
> 	> Which package is it? Does it also happen for CRAN packages?
> 	> I guess any security setting either on the Server or the client
> are 
> 	> blocking the installation. But it is really hard to guess what it
> really 
> 	> is... You might want to ask your local IT stuff.
> 
> 	> Uwe Ligges
> 
> 	Thanks for your e-mail message. Yes, the share has been mounted on a
> drive letter P.
> 	Unfortunately, it happens for all packages starting from abind...
> 	And it happens if I load a package directly from CRAN as well.
> 	Do you know which part of the R code creates this temporary file*
> directories in the library subdirectory?
Yes, really not hard to find: The second call within function 
unpackPkg() in install.packages().


Uwe Ligges


> 	Rainer Walke
> 
> 
> 
> +++++
> This mail has been sent through the MPI for Demographic Research.  Should
you receive a mail that is apparently from a MPI user without this text
displayed, then the address has most likely been faked.   If you are uncertain
about the validity of this message, please check the mail header or ask your
system administrator for assistance.

On Fri, 13 Aug 2004, Walke, Rainer wrote:
> 	Do you know which part of the R code creates this temporary file*
> directories in the library subdirectory?
Why don't *you* know?  It is install.packages, surprisingly enough, in its
internal function unpackPkg, and running that under debug would show you
what is going on.  Once again, remember only you can do this as we cannot 
reproduce your claims.

Do remember you have already been told that you are using an unsupported 
OS, and quite possible a file system that has never been tested and is not 
supported by the compilers we use to build R.

One possible issue is that code uses

                file.rename(file.path(tmpDir, curPkg), instPath)

Internally that boils down to

int Rwin_rename(char *from, char *to)
{
    int res = 0;
    OSVERSIONINFO verinfo;

    verinfo.dwOSVersionInfoSize = sizeof(OSVERSIONINFO);
    GetVersionEx(&verinfo);
    switch(verinfo.dwPlatformId) {
    case VER_PLATFORM_WIN32_NT:
	res = (MoveFileEx(from, to, MOVEFILE_REPLACE_EXISTING) == 0);
	break;
    default:
	if (!DeleteFile(to) && GetLastError() != ERROR_FILE_NOT_FOUND)
	    return 1;
	res = (MoveFile(from, to) == 0);
    }
    return res;
}

Now, what your unsupported OS reports for dwPlatformId is undocumented in 
the MinGW header files (and in the VC6 docs), and your OS did not exist 
when that was written.  Given the choices

#define VER_PLATFORM_WIN32s 0
#define VER_PLATFORM_WIN32_WINDOWS 1
#define VER_PLATFORM_WIN32_NT 2

it is the third according the Microsoft's current Platform SDK, but is 
that correct (it seems to predate the release of your OS)?  Please check 
it for us.

BDR

-- 
Brian D. Ripley,                  ripley@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 don't *you* know?  It is install.packages, surprisingly enough,
in its
	>internal function unpackPkg, and running that under debug would
show you
	>what is going on.  Once again, remember only you can do this as we
cannot 
	>reproduce your claims.

	>Do remember you have already been told that you are using an
unsupported 
	>OS, and quite possible a file system that has never been tested and
is not 
	>supported by the compilers we use to build R.

	>One possible issue is that code uses
>  >               file.rename(file.path(tmpDir, curPkg), instPath)
> 
	>Internally that boils down to

	>int Rwin_rename(char *from, char *to)
	>{
	>    int res = 0;
	>   OSVERSIONINFO verinfo;

	>    verinfo.dwOSVersionInfoSize = sizeof(OSVERSIONINFO);
	>    GetVersionEx(&verinfo);
	>    switch(verinfo.dwPlatformId) {
	>    case VER_PLATFORM_WIN32_NT:
	>	res = (MoveFileEx(from, to, MOVEFILE_REPLACE_EXISTING) =0);
	>	break;
	>    default:
	>	if (!DeleteFile(to) && GetLastError() !ERROR_FILE_NOT_FOUND)
	>	    return 1;
	>	res = (MoveFile(from, to) == 0);
	>   }
	>    return res;
	>}

	>Now, what your unsupported OS reports for dwPlatformId is
undocumented in 
	>the MinGW header files (and in the VC6 docs), and your OS did not
exist 
	>when that was written.  Given the choices

	>#define VER_PLATFORM_WIN32s 0
	>#define VER_PLATFORM_WIN32_WINDOWS 1
	>#define VER_PLATFORM_WIN32_NT 2

	>it is the third according the Microsoft's current Platform SDK, but
is 
	>that correct (it seems to predate the release of your OS)?  Please
check 
	>it for us.

	>BDR

	
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sysinfo/bas
e/osversioninfo_str.asp
	says that VER_PLATFORM_WIN32_NT denotes
	WinNT, Win2000, WinXP and Win2003 Server

	dwMinorVersion is different 
	Windows Server 2003	2
	Windows XP			1
	Windows 2000			0
	Windows NT 4.0			0

	dwMajorVersion
	Windows Server 2003	5
	Windows XP			5
	Windows 2000			5
	Windows NT 4.0			4

	Further I checked
	
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/base
/movefileex.asp
	about the movefileex command:
	Client: Requires Windows XP, Windows 2000 Professional, or Windows
NT Workstation.
	Server: Requires Windows Server 2003, Windows 2000 Server, or
Windows NT Server.
	Unicode: Implemented as Unicode and ANSI versions.
	Header: Declared in Winbase.h; include Windows.h.
	Library: Use Kernel32.lib.
	It seems that MoveFileEx should work without any change on NT, W2000
WinXP and Windows 2003.
      Now I think it is more a Windows than a R problem.
	Rainer Walke



+++++
This mail has been sent through the MPI for Demographic Rese...{{dropped}}

Applying SP2 for Windows XP solves this problem.

I do not know the reason for the behaviour. But it could be something like
described in MS knowledge base article 839027 (byte range locking).

Thanks,
Rainer Walke






+++++
This mail has been sent through the MPI for Demographic Rese...{{dropped}}