similar to: install.packages, normalizePath, file permissions

Windows XP. I have just updated to R 2.11.0 and then run update.packages. In the series of updates, a few will succeed, then I get a failure like package 'mvtnorm' successfully unpacked and MD5 sums checked package 'party' successfully unpacked and MD5 sums checked package 'PBSmodelling' successfully unpacked and MD5 sums checked Error in normalizePath(path) :

I didn't load the package. I wasn't able to do that, since I wasn't successfull to install it in first place with install.packages. -----Original Message----- From: Uwe Ligges [mailto:ligges@statistik.uni-dortmund.de] Sent: pon 2005-03-14 15:34 To: Gorjanc Gregor Cc: r-devel@stat.math.ethz.ch Subject: Re: [Rd] Package Installation in RGui (PR#7262) Under Windows, you cannot update /

I'm trying to update my Matrix package given the update last night. But the following error is generated. I've tried restarting R and deleting my old Matrix package. Can anyone suggest how this might be resolved? > install.packages('Matrix') trying URL 'http://www.ibiblio.org/pub/languages/R/CRAN/bin/windows/contrib/2.1/Mat rix_0.98-1.zip' Content type

Hi Jiefei, the change in handling trailing path separators is not on purpose, but is a byproduct of a new implementation of normalizePath, which now handles symbolic links and normalizes case in long path names. It is not documented what happens to trailing separators, and hence portable programs should not depend on it. I don't think it is a property that should be documented/specified.

Hello, I discovered a bug or undocumented behavior in normalizePath steps to reproduce: execute normalizePath on a folder link on windows. When you are on a non-english windows box, you likely have links in place for windows' default folders, e.g. "C:\Programme" linking to "C:\Program Files" on german windows boxes. Thus executing

>>> Uwe Ligges <ligges at statistik.tu-dortmund.de> 04/10/09 4:21 PM >>> >Well, you need to ask Symantec to fix Norton, hence this is the >wrong address. That would not help other R users who were looking in the archives for help with what looked like a mysterious normalizePath error, would it? As I said, the principal intent of the posting was to point to a

The fs[1] function `fs::path_abs()` does what I believe you were expecting `normalizePath()` to do in this case. e.g. setwd("~") normalizePath("foo/bar") #> Warning in normalizePath("foo/bar") : #> path[1]="foo/bar": No such file or directory #> [1] "foo/bar" fs::path_abs("foo/bar") #>

In researching another issue, I discovered a workaround: the network drive folder needs to be mapped to the local PC. setwd("//Hzndhhsvf2/data/OCPH/EPI/BHSDM/Group/Michael Laviolette/Stat tools") df1 <- readxl::read_excel("addrlist-4-MikeL.xls", 2) # fails, throws same error df2 <- readxl::read_excel("Z:/Stat

I wonder if this could be related to the issue that I submitted to bugzilla about two months ago? ( https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=17159) That is to say, could it be that it's treating the first path after the single backslash as an actual directory, rather than as the name of the share? -- Evan Cortens, PhD Institutional Analyst - Office of Institutional Analysis

If we are fiddling with normalizePath, having a way of not following symlinks (otheer than ~) would be useful as well. I had to write normalizePath2 in switchr for a specific on-the-ground need to NOT go down all he way to physical paths on a remote compute system because of how IT handled implementing constant pathing on top of swapping out hardware, and I can't imagine i'm the only

Dear all, I'm not sure whether this is intended behaviour or a bug. The path returns from normalizePath is different when the directory doesn't exist. I have included a reproducible example. path <- tempfile() missing.dir <- normalizePath(path, winslash = "/", mustWork = FALSE) dir.create(path) existing.dir <- normalizePath(path, winslash = "/", mustWork =

Hi all, I saw a quite surprising result in the devel R when using the function *normalizePath*. If the input is a path to a folder, the function returns an absolute path with/without a slash at the end depending on the existence of the folder. I know both results are valid on Windows but this behavior is different than R3.6, I do not know if the change in the devel version is made on purpose.

I'm having an issue with occasionally slow-running calls to normalizePath. If the path is a non-existent UNC path, then normalizePath sometimes takes 6 or 7 seconds to run, rather than its usual few microseconds. My big problem is that I can't reliably reproduce this across machines. The example below generates one or two slow runs out of 10000 on my Windows machine. I haven't been

Hi I have been trawling the web, FAQs, and R manuals for help on the following issue, but have failed and was wondering if anyone has a solution to the following problem: After having installed R 2.6.2 for Windows (binary), I tried to install various packages. Every time I try loading a package (any package) via the built-in menu, I run into the following error message. >

Hi, I update R from 2.10 to 2.13. Then I find soma problems when I start R. Warning infos as below: ##### Warning message: In normalizePath(c(new, .Library.site, .Library), "/") : path[1]="": No such file or directory R version 2.13.1 (2011-07-08) Copyright (C) 2011 The R Foundation for Statistical Computing ISBN 3-900051-07-0 Platform: x86_64-pc-linux-gnu (64-bit) R is

The packages "readxl" and "haven" (and possibly others) no longer access files on shared network drives. The problem appears to be in the normalizePath() function. The file can be read from a local drive or by functions that don't call normalizePath(). The error thrown is Error: path[1]="\\Hzndhhsvf2/data/OCPH/EPI/BHSDM/Group/17.xls": The system cannot find the

I found this as well. At our institution, our home directories are on network shares that are mapped to local drives. The default, it appears, is to set the location for libraries (etc) to the network share name (//computer//share/director/a/b/user) rather than the local drive mapping (H:/). Given the issue with dir.create(), this means it's impossible to install packages (since it tries to

I've been getting the following warning after running 'install.packages()' recently: Warning message: insufficient OS support on this platform in: normalizePath(path) Does anyone know what this means? And does anyone know how I can get rid of the warning? I've just installed R on a fresh FC5 system so I feel I might have forgotten to install a package/library or something.

Full_Name: Joseph Haykov Version: 2.8.0 OS: Windows Submission from: (NULL) (216.189.177.202) normalizePath("C:\\DOCUME~1\\JOSEPH~1\\LOCALS~1\\Temp\\RtmpolZ4Vy\\file72ae2cd6.txt") returns: "\0354xl|\a&#144;\001?$v\001?y8" instead of returning: "C:\\Documents and Settings\\Joseph Haykov\\Local Settings\\Temp\\RtmpolZ4Vy\\file72ae2cd6.txt" By the way, this

>>>>> Evan Cortens <ecortens at mtroyal.ca> >>>>> on Thu, 17 Nov 2016 15:51:03 -0700 writes: > I wonder if this could be related to the issue that I > submitted to bugzilla about two months ago? ( > https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=17159) > That is to say, could it be that it's treating the first >