[
https://issues.apache.org/jira/browse/LUCENE-10457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17503016#comment-17503016
]
Mike Drob commented on LUCENE-10457:
------------------------------------
> Sorry, a symbolic link is a whole different thing than a file. It has
> different semantics / platform specifics, etc. A symlink to a directory is
> not a directory.
In what ways? If you pass a symlink to a directory to {{Files.isDirectory}} it
will return true. You have to specifically ask Java for
{{Link_Option.NOFOLLOW}} to get the distinction.
> I'm a hard -1 to randomly doing this from LuceneTestCase.
Like I said earlier, LuceneTestCase isn't the only place that could handle
this. Would you be similarly opposed to a FilterFileSystem that does this?
> It isn't just fixing a test or two, its the ongoing costs of having confusing
> tests. It is literally 3 lines of code for you to do this in your
> symlink-using test.
Maybe some additional context for my motivation would be helpful? We had an
issue with symlinks in Solr; it wasn't a Lucene related problem; we fixed it;
everybody is happy and moved on. I started wondering what other places might be
susceptible to mishandling symlinks. Instead of trying to individually search
for every single place our code that could be affected, I started looking for
common areas that might yield high returns.
Switching LuceneTestCase.createTempDir to sometimes return symlinks to
directories broke exactly three places in Lucene code. Those are easy to
reproduce with three lines of code like you suggest. The concern is that I
wouldn't have found those three places without a larger, more general change
that sprayed symlinks all over the place. And we won't find similar issues in
the future, which is the point of the randomized testing framework in the first
place. Have a robust testing framework and find issues that we don't even know
exist.
For example, right now, running {{IndexSplitter <srcDir> <destDir>
<segments>+}} doesn't work when {{destDir}} is a symlink to a directory. How
did I know? I wasn't looking for IndexSplitter issues. Should it work? I would
imagine yes. Or at the very least, give a better error than it currently does.
The core indexing and querying library never has to worry about symlinks, sure.
But we have plenty of operational tools that interact with the filesystem as
defined by users. And we don't control that.
> LuceneTestCase.createTempDir could randomly return symbolic links
> -----------------------------------------------------------------
>
> Key: LUCENE-10457
> URL: https://issues.apache.org/jira/browse/LUCENE-10457
> Project: Lucene - Core
> Issue Type: Task
> Components: general/test
> Reporter: Mike Drob
> Priority: Major
>
> When we are creating temporary directories to use for other Lucene functions,
> we could occasionally provide symbolic links instead of direct references to
> directories. If the system running tests doesn't support symbolic links, then
> we should ignore this option.
> Providing links would be useful to test scenarios for example where users
> have a symbolic link for the "current" index directory and then rotate that
> over time but applications still use the same link.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
