I installed NIS 2009 on a new samsung nc20 running win XP Home.
I use the open-soource statistics package R. That allows extension via installed 'packages', managed by the install.packages() routine in R.
packages are successfully downloaded from the CRAN repository, but installation then fails; an example is shown below:
> package 'Matrix' successfully unpacked and MD5 sums checked > Error in normalizePath(path) : > path[1]: The system cannot find the file specified
The failure to find the downloaded file seems to be due to NIS. If I disable autoprotection, package installation works fine. If I re-enable it - same error.
On systems without NIS I have no problem.
I have reproduced the problem with several R package installs of various sizes, some of which download different numbers of temporary files.
Marking the relevant temporary folder as an exclusion does not fix the problem.
I conclude that NIS is interrupting file access for long enough that the system is reporting a file access error, possibly during a C routine call to realpath() which I think is the only place where the file actually has to be present in R's normalizePath call.
The work-round is to disable auto-protect when installing R packages, but for obvious reasons it would be nice if the problem was resolved.
Have you allowed all of the executables required by R in NIS. Rtools29.exe, the installer would need to be allowed, assuming you have the latest version. There may also be some .dll files that will specifically need to be allowed. The Perl executables will also need to be allowed.
Have a look at what you can add to NIS to allow what you need to allow after the download. Most will be in the Rtools as it seems to be the most important part of the software.
While R application installation _can_ use the toolset described above, the usual Windows install does not require them (for example, Perl is not required) as the usual Windows install is straight from windows binary, not via compilation. Further, package installation - which is what Norton is interrupting - is managed directly by the Rgui.exe, which is most certainly 'allowed' by NIS; this is obvious because the point of failure _follows_ internet access, package repository query, and download of the necessary temporary files. It is only _after_ all this has happened that R reports an error, at the point that the R executable attempts to open the temporary files to unpack the extension. Thus, NIS is not interfering with R's internet access; only with local file access after download.
Marking the temporary file area used for this purpose as a scan exemption did not remove the issue; disabling on-access scanning did.
Are you able to set up a custom scan to check the file after the download prior to installation. It is a similar problem with rar. and zip files, perhaps, in that they aren't scanned prior to execution. Since your download is temp files, Norton may decide that it is safe, or otherwise, we might identify the one or two files inside the download that it is objecting to.
How is the material downloaded? Via browser? or some sort of proxy?