To clarify, these issues are about deleting the contents of the home
directory, not the directory itself, which cannot be deleted by ordinary
users on today's systems. Unfortunately this has to be fixed in the code
that calls unlink(), such code must be aware of the expansions. The "R
CMD build" case as you write has been fixed, if anyone finds any other
instance of this problem in base R, please report, it will be fixed as
well. The new argument "expand" has been added to unlink() to make these
fixes easier.
A variation on what you propose: tilde ("~") is now treated the same way
as "." and ".." have already been by unlink(), which means it will never
be considered for deletion (not even with expand=TRUE). There are still
a number of ways to delete the contents of one's home directory,
including tilde expansion with user name, with directory separators,
etc. This special treatment of "~" will prevent only one pattern of the
problem. One should always be careful when recursively/programmatically
deleting files.
Also, the new behavior can cause trouble in some cases when a file or
directory named tilde exists, but hopefully not as bad as deleting the
contents of user home directory. In principle, such file can still be
deleted from R using a combination of tilde and wildcards with wildcard
expansion enabled.
Best
Tomas
On 2/26/20 11:47 PM, Gábor Csárdi wrote:
!!! DON'T TRY THE CODE IN THIS EMAIL AT HOME !!!
Well, unlink() does what it is supposed to do, so you could argue that
there is nothing wrong with it. Also, nobody would call unlink() on
"~", right?
The situation is not so simple, however. E.g. if you happen to have a
directory called "~", and you iterate over all files and directories
to selectively remove some of them, then your code might end up
calling unlink on the local "~" directory, and then your home is gone.
But you would not create a directory named "~", that is just asking
for trouble. Well, surely, _intentionally_ you would not do that.
Unintentionally, you might. E.g. something like this is enough:
# Create a subpath within a base directory
badfun <- function(base = ".", path) {
dir.create(file.path(base, path), recursive = TRUE, showWarnings = FALSE)
}
badfun(path = "~/foo")
(If you did run this, be very careful how you remove the directory called "~"!)
A real example is `R CMD build` which deletes the home directory of
the current user if the root of the package contains a non-empty "~"
directory. Luckily this is now fixed in R-devel, so R 4.0.0 will do
better. (R 3.6.3 will not.) See
https://github.com/wch/r-source/commit/1d4f7aa1dac427ea2213d1f7cd7b5c16e896af22
I have seen several bug reports about various packages (that call R
CMD build) removing the home directory, so this indeed happens in
practice to a number of people. The commit above will fix `R CMD
build`, but it would be great to "fix" this in general.
It seems pretty hard to prevent users from creating of a "~"
directory. But preventing unlink() from deleting "~" does not actually
seem too hard. If unlink() could just refuse removing "~" (when expand
= TRUE), that would be great. It seems to me that the current behavior
is very-very rarely intended, and its consequences are potentially
disastrous.
If unlink("~", recursive = TRUE) errors, you can still remove a local
"~" file/dir with unlink("./~", ...). And you can still remove your
home directory if you really want to do that, with
unlink(path.expand("~"), ...). So no functionality is lost.
Also, if anyone is aware of packages/functions that tend to create "~"
directories or files, please let me know.
I would be happy to submit a patch for the new unlink("~") behavior.
Thanks,
Gabor
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
