[Rd] normalizePath bug (PR#13199)

[Joseph Haykov]

No, it's working fine if the file is there, and as I mentioned before, I  
can just normalize the path, and then append the file name at the end  
using the file.path function.

Thanks for your help.


On Thu, 23 Oct 2008 14:24:42 -0400, Duncan Murdoch <murdoch at stats.uwo.ca>  
wrote:

> On 10/23/2008 1:59 PM, Joseph Haykov wrote:
>> Actually, it's a new file that I plan on writing to, so while the   
>> directory C:\\DOCUME~1\\JOSEPH~1\\LOCALS~1\\Temp\\RtmpolZ4Vy exists,  
>> the  file file72ae2cd6.txt does not. However, this was working fine in  
>> version  2.6.2. If you're saying that the reason why this doesn't work  
>> is because  the file does not exist, I can easily work around the issue.
>
> That's a likely cause.  2.7.0 changed the method of normalizing the  
> path, and it now relies on Windows API calls to do it.  However, up to  
> 2.8.0 it wasn't checking for an error return from those.  I've fixed  
> that now, so your string now gives me
>
>  >  
> normalizePath("C:\\DOCUME~1\\JOSEPH~1\\LOCALS~1\\Temp\\RtmpolZ4Vy\\file72ae2cd6.txt")
> Error in normalizePath(path) : Unable to normalize element 1
>
> The Windows docs don't list all possible reasons for an error return, so  
> I'm not sure that's what you saw, but it does seem likely.  Please do  
> let me know if creating the file is not sufficient to get it to work for  
> you.
>
> Duncan Murdoch
>
>>  Best regards,
>>   Joe Haykov
>>   On Thu, 23 Oct 2008 13:49:42 -0400, Duncan Murdoch  
>> <murdoch at stats.uwo.ca>  wrote:
>>
>>> On 10/23/2008 10:45 AM, joe at novelcap.com wrote:
>>>> 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 works correctly in version 2.6.2
>>>
>>> I see the problem, and will look into it.  It first started failing  
>>> in  2.7.0; it's not a new bug.
>>>
>>> But I'm not sure it's a bug, since that directory doesn't exist on my   
>>> system, and the function is documented to give undefined results in  
>>> that  case.  Does that file exist on your system?
>>>
>>> Duncan Murdoch
>>
>