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