[
https://issues.apache.org/jira/browse/IO-807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17801698#comment-17801698
]
Jordi Sola commented on IO-807:
-------------------------------
Hi [~elharo]
I don´t have the source available right now, so take my following comments with
a bit of salt.
I think the semantics for LinkOption.NOFOLLOW_LINKS is unclear here, or at
least undocumented (even in Oracle docs). And this is causing a lot of "WOWs"
In my mind, the default behaviour (follow links) means that links are always
resolved. So, if we have /home/bar/linkfile --> /tmp/foo.txt --> "Hello", then
the copy generates /home/baz/linkfile --> "Hello" (the copy is not a symlink
anymore!)
Then, LinkOption.NOFOLLOW_LINKS means that links are never resolved, so they
are retained (copied?) as links. So the same copy than before becomes
/home/baz/linkfile --> /tmp/foo.txt --> "Hello".
I think that semantics also cover the "move" situation you just depicted.
If we have /home/bar/linktobar.txt --> /home/bar/bar.txt --> "Hello" and we
move /home/bar to /home/baz then:
* The default (FOLLOW_LINKS) should create two files, both with the same
content: /home/baz/linktobar.txt --> "Hello" and /home/baz/bar.txt --> "Hello"
* NOFOLLOW_LINKS should create one file, and retain the link "as is":
/home/baz/bar.txt --> "Hello" and /home/baz/linktobar.txt --> /home/bar/bar.txt
--> "Hello"
Note that the new link retains it original value, to `/home/bar`, not to
`/home/baz`. This is caused because the "value" of the link is an absolute path.
But links can also have a "value" of relative paths.
If we have /home/bar/linktobar.txt --> ./bar.txt (relative path), then things
change a bit.
* The default behaves the same (creates to files, none is a symlink)
* NOFOLLOW_LINKS moves `/home/bar/bar.txt` to `/home/baz/bar.txt` (as before),
and creates the link. The "value" of the link is unchanged, so it ends as
`/home/baz/linktobar.txt`–> ./bar.txt --> "Hello"
IMHO, those semantics are sane, and reduces the number of "WOWs" from users.
Also, we can "easily" implement them (I have a PR half there).
Also, those semantics gracefully handle another can-of-worms related to links:
broken links.
* NOFOLLOW_LINKS can ignore if the link is broken or not: just copy/move the
"value" of the link.
* The default (FOLLOW_LINKS) needs to resolve the actual value of the link, so
copy/move operations involving broken links MUST ALWAYS raise an exception.
> FileUtils.requireExists does not take into account soft links
> -------------------------------------------------------------
>
> Key: IO-807
> URL: https://issues.apache.org/jira/browse/IO-807
> Project: Commons IO
> Issue Type: Improvement
> Components: Utilities
> Affects Versions: 2.13.0
> Reporter: Jordi Sola
> Priority: Major
>
> The current sources for `FileUtils.requireExists` and `FileUtils.
> requireExistsChecked` just check for the existence of the file, delegating to
> the `File.exists` method:
> {code:java}
> Objects.requireNonNull(file, fileParamName);
> if (!file.exists()) {
> throw ...
> }
> return file;{code}
> The default `file` implementation returns `false` if the file is a broken
> symbolic link (that is, a symbolic link pointing to an non-existing file).
> While this implementation can be seen as correct most of the time, sometimes
> we need to avoid following the link, and evaluate the existence of the link
> itself.
> For example, when using `FileUtils#copyDirectory` with the
> `LinkOption.NOFOLLOW_LINKS` option, it is expected that broken links are
> copied (see JavaDocs for `java.nio.file.Files#copy`). Nonetheless, as
> `FileUtils#requireFileIfExists` returns `false`, the file is just ignored.
>
> One possible approach is relying in `java.nio.file.Files#isSymbolicLink` when
> `LinkOption.NOFOLLOW_LINKS` options is provided.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
