[
https://issues.apache.org/jira/browse/IO-845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17830158#comment-17830158
]
Gary D. Gregory commented on IO-845:
------------------------------------
Another interesting use case is dealing with drives/volumes/mounts.
For example, if I copy C:\test1 to D:\test2 (USB or network) and take
(disconnect) Drive D to another machine, I expect all the bytes to be there,
symlinks or not. If the source has a symlink outside of itself, I'd still
expect the bytes to come with me. Is that case handled in all of the above and
the PR?
Do we need a new copyDirectoryGraph() API that always copies links as links?
> Copying symbolic links. how should FileUtils.copyDirectory. behave?
> -------------------------------------------------------------------
>
> Key: IO-845
> URL: https://issues.apache.org/jira/browse/IO-845
> Project: Commons IO
> Issue Type: Bug
> Reporter: Elliotte Rusty Harold
> Priority: Major
>
> The current 2.15.1 release and earlier versions have bugs in the copying of
> symbolic link cycles using FileUtils.copyDirectory. There are also bugs in
> copying broken symbolic links reported in IO-807. These are fixed at head
> because symbolic links to directories are now copied as symbolic links rather
> than by resolving the files. However this causes problems for some
> non-hypothetical existing code that relied on the old behavior for copying
> directories containing non-cyclical symbolic links.In particular, Google has
> [reported failures in some of their internal
> projects|https://github.com/apache/commons-io/commit/ec4144b01b4107d6b39f5f4d784cf05217ea4dfa#commitcomment-137567006]
> when using the version at head as a result of this. However I don't think
> that the directories Google is copying contain cycles, so they weren't
> hitting the old bugs.
> The question is how to resolve this so that FileUtils.copyDirectory behaves
> reasonably with all possible directories whether cycles are present or not.
> Is there a consistent and reasonable way we can or should copy some links to
> directories as directories and others as actual directories? There are a
> number of cases to consider:
> 1. No symbolic links. Just copy everything and we're good.
> 2. Symbolic links but only to files, not directories. Copy the file or copy
> the link?
> 3. Symbolic links but only to files within the root directory being copied.
> Right now at head we create a link to the old directory in the source. We
> could instead create a link to the new directory in the target.
> 4. Symbolic links to files outside the root directory being copied. Right now
> at head we create a link to the old directory in the source. We should
> probably keep this behavior.
> I think the behavior we want is as follows, and then I think we handle most
> use cases while avoiding cycle problems:
> 1. Start from a root directory, the source.
> 2. Never copy anything that is not contained in that directory to the target.
> 3. When walking the directory tree, if a symbolic link is encountered:
> 3.1 If the symbolic link points outside the source, create a new symbolic
> link to the same target.
> 3.2 If the symbolic link points to a target inside the source, create a new
> symbolic link to the copy of the target.
> However every symbolic link in the source turns into a symbolic link in the
> copy. Cycles do not cause problems because they are not followed. The only
> discrepancy I see in this approach is that a link to a directory outside the
> source that is a link that points back into the source still points back into
> the source, not the target. Thus the copy can point back into the source
> indirectly. Perhaps when copying links that point outside the source we can
> fully resolve them to and repoint as needed.
> I don't know that this actually fixes Google's problem. They sort of want
> files if not directories to be resolved when copying. Maybe that's a
> argument. Maybe that's a separate method like
> FileUtils.actualizeFiles(directory) that walks a file tree and replaces every
> link to a file with the contents of the target file.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
