Possible bug: file.exists() always returns TRUE for prn.us.txt

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Possible bug: file.exists() always returns TRUE for prn.us.txt

Joris FA Meys
Dear all,

while preparing some exercises I came across some highly surprising
behaviour of file.exists(). The specific value "prn.us.txt" always returns
TRUE, even though that file is nowhere to be found on my system.

In a fresh R session 3.4.4 installed on Windows 10:

> grep("prn.us.txt", dir(recursive = TRUE))
integer(0)
> file.exists("prn.us.txt")
[1] TRUE
> file.exists("pnr.us.txt")
[1] FALSE
> file.exists("prn\\.us\\.txt")
[1] FALSE

> sessionInfo()
R version 3.4.4 (2018-03-15)
Platform: x86_64-w64-mingw32/x64 (64-bit)
Running under: Windows 10 x64 (build 16299)

Matrix products: default

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

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base

loaded via a namespace (and not attached):
[1] compiler_3.4.4

This also happens in 3.4.3, 3.4.2 and 3.4.1 . It is confirmed by Roman
Lustrik on his system as well :
https://twitter.com/romunov/status/977486929380995072

I suspect this is a bug, or I must be missing something completely.

Cheers
Joris

--
Joris Meys
Statistical consultant

Department of Data Analysis and Mathematical Modelling
Ghent University
Coupure Links 653, B-9000 Gent (Belgium)
<https://maps.google.com/?q=Coupure+links+653,%C2%A0B-9000+Gent,%C2%A0Belgium&entry=gmail&source=g>

-----------
Biowiskundedagen 2017-2018
http://www.biowiskundedagen.ugent.be/

-------------------------------
Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php

        [[alternative HTML version deleted]]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Possible bug: file.exists() always returns TRUE for prn.us.txt

Duncan Murdoch-2
On 24/03/2018 6:16 AM, Joris Meys wrote:
> Dear all,
>
> while preparing some exercises I came across some highly surprising
> behaviour of file.exists(). The specific value "prn.us.txt" always returns
> TRUE, even though that file is nowhere to be found on my system.

That's a Windows "bug", not an R bug.  Any name starting "prn" (upper or
lowercase), followed by an extension (i.e. a dot and characters) is
taken to be the DOS printer device.  According to Writing R Extensions,
names starting with "‘con’, ‘prn’, ‘aux’, ‘clock$’, ‘nul’, ‘com1’ to
‘com9’, and ‘lpt1’ to ‘lpt9' (possibly followed by extensions) are also
bad.  You can Google "PRN filename in Windows" to find lots of people
confused by this.  One page I get is

https://msdn.microsoft.com/en-us/library/aa365247(VS.85).aspx

but there's no guarantee that will work five minutes from now.

Duncan Murdoch

>
> In a fresh R session 3.4.4 installed on Windows 10:
>
>> grep("prn.us.txt", dir(recursive = TRUE))
> integer(0)
>> file.exists("prn.us.txt")
> [1] TRUE
>> file.exists("pnr.us.txt")
> [1] FALSE
>> file.exists("prn\\.us\\.txt")
> [1] FALSE
>
>> sessionInfo()
> R version 3.4.4 (2018-03-15)
> Platform: x86_64-w64-mingw32/x64 (64-bit)
> Running under: Windows 10 x64 (build 16299)
>
> Matrix products: default
>
> locale:
> [1] LC_COLLATE=English_United Kingdom.1252
> [2] LC_CTYPE=English_United Kingdom.1252
> [3] LC_MONETARY=English_United Kingdom.1252
> [4] LC_NUMERIC=C
> [5] LC_TIME=English_United Kingdom.1252
>
> attached base packages:
> [1] stats     graphics  grDevices utils     datasets  methods   base
>
> loaded via a namespace (and not attached):
> [1] compiler_3.4.4
>
> This also happens in 3.4.3, 3.4.2 and 3.4.1 . It is confirmed by Roman
> Lustrik on his system as well :
> https://twitter.com/romunov/status/977486929380995072
>
> I suspect this is a bug, or I must be missing something completely.
>
> Cheers
> Joris
>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Possible bug: file.exists() always returns TRUE for prn.us.txt

Joris FA Meys
Thank you. I was just replying my own message with the same information.
Sorry for not doing the research properly before filing.

Cheers
Joris

On Sat, Mar 24, 2018 at 11:36 AM, Duncan Murdoch <[hidden email]>
wrote:

> On 24/03/2018 6:16 AM, Joris Meys wrote:
>
>> Dear all,
>>
>> while preparing some exercises I came across some highly surprising
>> behaviour of file.exists(). The specific value "prn.us.txt" always returns
>> TRUE, even though that file is nowhere to be found on my system.
>>
>
> That's a Windows "bug", not an R bug.  Any name starting "prn" (upper or
> lowercase), followed by an extension (i.e. a dot and characters) is taken
> to be the DOS printer device.  According to Writing R Extensions, names
> starting with "‘con’, ‘prn’, ‘aux’, ‘clock$’, ‘nul’, ‘com1’ to ‘com9’, and
> ‘lpt1’ to ‘lpt9' (possibly followed by extensions) are also bad.  You can
> Google "PRN filename in Windows" to find lots of people confused by this.
> One page I get is
>
> https://msdn.microsoft.com/en-us/library/aa365247(VS.85).aspx
>
> but there's no guarantee that will work five minutes from now.
>
> Duncan Murdoch
>
>
>
>> In a fresh R session 3.4.4 installed on Windows 10:
>>
>> grep("prn.us.txt", dir(recursive = TRUE))
>>>
>> integer(0)
>>
>>> file.exists("prn.us.txt")
>>>
>> [1] TRUE
>>
>>> file.exists("pnr.us.txt")
>>>
>> [1] FALSE
>>
>>> file.exists("prn\\.us\\.txt")
>>>
>> [1] FALSE
>>
>> sessionInfo()
>>>
>> R version 3.4.4 (2018-03-15)
>> Platform: x86_64-w64-mingw32/x64 (64-bit)
>> Running under: Windows 10 x64 (build 16299)
>>
>> Matrix products: default
>>
>> locale:
>> [1] LC_COLLATE=English_United Kingdom.1252
>> [2] LC_CTYPE=English_United Kingdom.1252
>> [3] LC_MONETARY=English_United Kingdom.1252
>> [4] LC_NUMERIC=C
>> [5] LC_TIME=English_United Kingdom.1252
>>
>> attached base packages:
>> [1] stats     graphics  grDevices utils     datasets  methods   base
>>
>> loaded via a namespace (and not attached):
>> [1] compiler_3.4.4
>>
>> This also happens in 3.4.3, 3.4.2 and 3.4.1 . It is confirmed by Roman
>> Lustrik on his system as well :
>> https://twitter.com/romunov/status/977486929380995072
>>
>> I suspect this is a bug, or I must be missing something completely.
>>
>> Cheers
>> Joris
>>
>>
>


--
Joris Meys
Statistical consultant

Department of Data Analysis and Mathematical Modelling
Ghent University
Coupure Links 653, B-9000 Gent (Belgium)
<https://maps.google.com/?q=Coupure+links+653,%C2%A0B-9000+Gent,%C2%A0Belgium&entry=gmail&source=g>

-----------
Biowiskundedagen 2017-2018
http://www.biowiskundedagen.ugent.be/

-------------------------------
Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php

        [[alternative HTML version deleted]]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Possible bug: file.exists() always returns TRUE for prn.us.txt

Joris FA Meys
Sorry for coming back at this, but would it make sense to have
file.exists() return FALSE when it only finds one of these device names?
Using backslashes to escape the dots makes file.exists() return the correct
result. I got caught by this when I created file names based on a set of
stock market tickers, so I can imagine this could happen to other people
too.

Cheers
Joris

On Sat, Mar 24, 2018 at 11:38 AM, Joris Meys <[hidden email]> wrote:

> Thank you. I was just replying my own message with the same information.
> Sorry for not doing the research properly before filing.
>
> Cheers
> Joris
>
> On Sat, Mar 24, 2018 at 11:36 AM, Duncan Murdoch <[hidden email]
> > wrote:
>
>> On 24/03/2018 6:16 AM, Joris Meys wrote:
>>
>>> Dear all,
>>>
>>> while preparing some exercises I came across some highly surprising
>>> behaviour of file.exists(). The specific value "prn.us.txt" always
>>> returns
>>> TRUE, even though that file is nowhere to be found on my system.
>>>
>>
>> That's a Windows "bug", not an R bug.  Any name starting "prn" (upper or
>> lowercase), followed by an extension (i.e. a dot and characters) is taken
>> to be the DOS printer device.  According to Writing R Extensions, names
>> starting with "‘con’, ‘prn’, ‘aux’, ‘clock$’, ‘nul’, ‘com1’ to ‘com9’, and
>> ‘lpt1’ to ‘lpt9' (possibly followed by extensions) are also bad.  You can
>> Google "PRN filename in Windows" to find lots of people confused by this.
>> One page I get is
>>
>> https://msdn.microsoft.com/en-us/library/aa365247(VS.85).aspx
>>
>> but there's no guarantee that will work five minutes from now.
>>
>> Duncan Murdoch
>>
>>
>>
>>> In a fresh R session 3.4.4 installed on Windows 10:
>>>
>>> grep("prn.us.txt", dir(recursive = TRUE))
>>>>
>>> integer(0)
>>>
>>>> file.exists("prn.us.txt")
>>>>
>>> [1] TRUE
>>>
>>>> file.exists("pnr.us.txt")
>>>>
>>> [1] FALSE
>>>
>>>> file.exists("prn\\.us\\.txt")
>>>>
>>> [1] FALSE
>>>
>>> sessionInfo()
>>>>
>>> R version 3.4.4 (2018-03-15)
>>> Platform: x86_64-w64-mingw32/x64 (64-bit)
>>> Running under: Windows 10 x64 (build 16299)
>>>
>>> Matrix products: default
>>>
>>> locale:
>>> [1] LC_COLLATE=English_United Kingdom.1252
>>> [2] LC_CTYPE=English_United Kingdom.1252
>>> [3] LC_MONETARY=English_United Kingdom.1252
>>> [4] LC_NUMERIC=C
>>> [5] LC_TIME=English_United Kingdom.1252
>>>
>>> attached base packages:
>>> [1] stats     graphics  grDevices utils     datasets  methods   base
>>>
>>> loaded via a namespace (and not attached):
>>> [1] compiler_3.4.4
>>>
>>> This also happens in 3.4.3, 3.4.2 and 3.4.1 . It is confirmed by Roman
>>> Lustrik on his system as well :
>>> https://twitter.com/romunov/status/977486929380995072
>>>
>>> I suspect this is a bug, or I must be missing something completely.
>>>
>>> Cheers
>>> Joris
>>>
>>>
>>
>
>
> --
> Joris Meys
> Statistical consultant
>
> Department of Data Analysis and Mathematical Modelling
> Ghent University
> Coupure Links 653, B-9000 Gent (Belgium)
>
> <https://maps.google.com/?q=Coupure+links+653,%C2%A0B-9000+Gent,%C2%A0Belgium&entry=gmail&source=g>
>
> -----------
> Biowiskundedagen 2017-2018
> http://www.biowiskundedagen.ugent.be/
>
> -------------------------------
> Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php
>



--
Joris Meys
Statistical consultant

Department of Data Analysis and Mathematical Modelling
Ghent University
Coupure Links 653, B-9000 Gent (Belgium)
<https://maps.google.com/?q=Coupure+links+653,%C2%A0B-9000+Gent,%C2%A0Belgium&entry=gmail&source=g>

-----------
Biowiskundedagen 2017-2018
http://www.biowiskundedagen.ugent.be/

-------------------------------
Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php

        [[alternative HTML version deleted]]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel