dir.exists(paths)
dir.create(path, showWarnings = TRUE, recursive = FALSE, mode = "0777")
Sys.chmod(paths, mode = "0777", use_umask = TRUE)
Sys.umask(mode = NA)path.expand) is done.path.expand) is done.mkdir -p.as.octmode. For Sys.chmod it is
recycled along paths.umask setting?dir.exists returns a logical vector of TRUE or
FALSE values (without names). dir.create and Sys.chmod return invisibly a logical vector
indicating if the operation succeeded for each of the files attempted.
Using a missing value for a path name will always be regarded as a
failure. dir.create indicates failure if the directory already
exists. If showWarnings = TRUE, dir.create will give a
warning for an unexpected failure (e.g., not for a missing value nor
for an already existing component for recursive = TRUE). Sys.umask returns the previous value of the umask,
as a length-one object of class "octmode": the
visibility flag is off unless mode is NA. See also the section in the help for file.exists on
case-insensitive file systems for the interpretation of path
and paths.dir.create creates the last element of the path, unless
recursive = TRUE. Trailing path separators are discarded.
On Windows drives are allowed in the path specification and unless
the path is rooted, it will be interpreted relative to the current
directory on that drive. mode is ignored on Windows.
The mode will be modified by the umask setting in the same way
as for the system function mkdir. What modes can be set is
OS-dependent, and it is unsafe to assume that more than three octal
digits will be used. For more details see your OS's documentation on the
system call mkdir, e.g. man 2 mkdir (and not that on
the command-line utility of that name). One of the idiosyncrasies of Windows is that directory creation may
report success but create a directory with a different name, for
example dir.create("G.S.") creates "G.S". This is
undocumented, and what are the precise circumstances is unknown (and
might depend on the version of Windows). Also avoid directory names
with a trailing space.
Sys.chmod sets the file permissions of one or more files.
It may not be supported on a system (when a warning is issued).
See the comments for dir.create for how modes are interpreted.
Changing mode on a symbolic link is unlikely to work (nor be
necessary). For more details see your OS's documentation on the
system call chmod, e.g. man 2 chmod (and not that on
the command-line utility of that name). Whether this changes the
permission of a symbolic link or its target is OS-dependent (although
to change the target is more common, and POSIX does not support modes
for symbolic links: BSD-based Unixes do, though).
The interpretation of mode in the Windows system functions is
non-POSIX and only supports setting the read-only attribute of the
file. So R interprets mode to mean set read-only if and only
if (mode & 0200) == 0 (interpreted in octal). Windows has a much
more extensive system of file permissions on some file systems
(e.g., versions of NTFS) which are unrelated to this system call. Sys.umask sets the umask and returns the previous value:
as a special case mode = NA just returns the current value.
It may not be supported (when a warning is issued and "0"
is returned). For more details see your OS's documentation on the
system call umask, e.g. man 2 umask.
All files on Windows are regarded as readable, and files being
executable is not a Windows concept. So umask only controls
whether a file is writable: a setting of "200" makes files (but
not directories) created subsequently read-only.
How modes are handled depends on the file system, even on Unix-alikes
(although their documentation is often written assuming a POSIX file
system). So treat documentation cautiously if you are using, say, a
FAT/FAT32 or network-mounted file system.file.info, file.exists, file.path,
list.files, unlink,
basename, path.expand.