From hb at stat.berkeley.edu  Mon Dec  1 21:03:00 2008
From: hb at stat.berkeley.edu (Henrik Bengtsson)
Date: Mon, 1 Dec 2008 12:03:00 -0800
Subject: [Rd] file.access() on network (mounted) drive on Windows Vista?
In-Reply-To: <alpine.LFD.2.00.0812011235250.10803@gannet.stats.ox.ac.uk>
References: <59d7961d0811261122v44f187a8s7f78512d264894bd@mail.gmail.com>
	<alpine.LFD.2.00.0812011235250.10803@gannet.stats.ox.ac.uk>
Message-ID: <59d7961d0812011203ydfb727fx8eeab4f1c6c85749@mail.gmail.com>

Hi,

thank you very much for this information.  I now know that it is safer
to use tryCatch() to test for this.

Details: I have a function pn <- getReadablePathname(pn) that I use to
assess that a pathname (which also follows Windows Shortcuts) passed
to a function specifies a file that exists and that can be read.  If
not, it throws an exception.  I only need to update this function to
try to open the file for reading ("rb") and then try to read a raw
byte (for an even more trusted result).  If this fails, I conclude
that the file is not a readable pathname.  I also have an analogus
getWritablePathname().

/Henrik

On Mon, Dec 1, 2008 at 4:44 AM, Prof Brian Ripley <ripley at stats.ox.ac.uk> wrote:
> It is a 'feature' of Windows Vista.  Why not just use tryCatch()?
> The older version of file.access() used to report access when there was
> none, so the error have happened both ways.
>
> (I think any OS with multiple filesystems potentially has problems like
> this: we saw them with Unix (Solaris) file systems mounted on MacOS X via
> Samba, even when the same thing works correctly on Linux.)
>
> On Wed, 26 Nov 2008, Henrik Bengtsson wrote:
>
>> Hi,
>>
>> I have a writable and readable file on a small network file system
>> (Cisco NSLU2 Unslung; non-NTFS) that I access via a mounted drive on
>> Windows Vista.  My problem could be due to a "funny" file
>> system/server, but here it goes:
>>
>>> pathname <- "Q:/foo.txt"
>>> cat(file=pathname, "Hello world!\n")
>>> readLines(pathname)
>>
>> [1] "Hello world!"
>>>
>>> file.info(pathname)
>>
>>          size isdir mode               mtime               ctime
>> Q:/foo.txt   14 FALSE  666 2008-11-26 11:45:53 2008-11-26 11:45:53
>>                        atime exe
>> Q:/foo.txt 2008-11-26 11:45:57  no
>>
>> The mode == 666 reported by file.info() indicates that it is readable
>> & writable by all users.  This is also what Windows Vista file
>> properties reports.  So far so good.  However, when I use
>> file.access() to test for file permissions, I get:
>>
>>> file.access(pathname, 0)  # 0 test for existence.
>>
>> Q:/foo.txt
>>        0
>>>
>>> file.access(pathname, 1) # 1 test for execute permission.
>>
>> Q:/foo.txt
>>       -1
>>>
>>> file.access(pathname, 2) # 2 test for write permission.
>>
>> Q:/foo.txt
>>       -1
>>>
>>> file.access(pathname, 4) # 4 test for read permission.
>>
>> Q:/foo.txt
>>       -1
>>
>> I obviously can write to and read from the file, and this is what
>> file.info()$mode says too.  However, file.access() tells a different
>> story.  More troubleshooting: When I log into the file server and do:
>>
>> # chmod ugo-w foo.txt
>> # ls -l foo.txt
>> -r-xr-----    1 admin    everyone       14 Nov 26 11:48 foo.txt
>>
>> The changes in permission are seen by file.info():
>>
>>> file.info(pathname)
>>
>>          size isdir mode               mtime               ctime
>> Q:/foo.txt   14 FALSE  444 2008-11-26 11:48:50 2008-11-26 11:48:50
>>                        atime exe
>> Q:/foo.txt 2008-11-26 11:56:40  no
>>
>> The output from file.access() remains the same though.
>>
>>> From help(file.info) I read:
>>
>>    File modes are probably only useful on NTFS file systems, and it
>>    seems all three digits refer to the file's owner. The
>>    execute/search bits are set for directories, and for files based
>>    on their extensions (e.g., '.exe', '.com', '.cmd' and '.bat'
>>    files).  'file.access' will give a more reliable view of
>>    read/write access availability to the R process.
>>
>>> From what I conclude, file.access() is not reliable in this case.  Is
>>
>> this a feature or a bug?
>>
>> I need a cross-platform test for file permissions, and I am looking
>> for safer workaround.  For instance, could it be that a zero result
>> from file.access() can be trusted, but a -1 could occur either from a
>> true lack of permission as well as a failure to test for the
>> permission?  If that would be case, I could try other measures (e.g.
>> try to open the file) whenever I receive a -1 before throwing an
>> exception.
>>
>> Any feedback or suggestions would be great.
>>
>> Thanks
>>
>> /Henrik
>>
>>> sessionInfo()
>>
>> R version 2.8.0 Patched (2008-10-21 r46766)
>> i386-pc-mingw32
>>
>> locale:
>> LC_COLLATE=English_United States.1252;LC_CTYPE=English_United
>> States.1252;LC_MON
>> ETARY=English_United States.1252;LC_NUMERIC=C;LC_TIME=English_United
>> States.1252
>>
>>
>> attached base packages:
>> [1] stats     graphics  grDevices utils     datasets  methods   base
>>
>> ______________________________________________
>> R-devel at r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>
> --
> Brian D. Ripley,                  ripley at 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
>



[Rd] file.access() on network (mounted) drive on Windows Vista?
Henrik Bengtsson