[
https://issues.apache.org/jira/browse/GEODE-8572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17209224#comment-17209224
]
ASF GitHub Bot commented on GEODE-8572:
---------------------------------------
jchen21 commented on a change in pull request #5595:
URL: https://github.com/apache/geode/pull/5595#discussion_r500657383
##########
File path:
geode-gfsh/src/main/java/org/apache/geode/management/internal/cli/util/LogExporter.java
##########
@@ -181,12 +180,13 @@ private long filterAndSize(Path originalLogFile) throws
IOException {
}
private List<Path> findFiles(Path workingDir, Predicate<Path> fileSelector)
throws IOException {
- Stream<Path> selectedFiles/* = null */;
if (!workingDir.toFile().isDirectory()) {
return Collections.emptyList();
}
- selectedFiles =
Files.list(workingDir).filter(fileSelector).filter(this.logFilter::acceptsFile);
-
- return selectedFiles.collect(toList());
+ return Files.list(workingDir)
+ .filter(Files::isRegularFile)
Review comment:
No, I am not saying I want to ignore the file it links to. Actually, I
am not sure when it should follow the link, or when it should not. Based on my
understanding, most likely, it should follow the link. You probably have more
context than I have. What I am trying to say is that `Files::isRegularFile` has
an option `NOFOLLOW_LINKS` for symbolic link. And symbolic link could be a
tricky case. As long as it works for the scenario as you expect, it should be
good.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> LogExporter throws if a directory matches its file selector
> -----------------------------------------------------------
>
> Key: GEODE-8572
> URL: https://issues.apache.org/jira/browse/GEODE-8572
> Project: Geode
> Issue Type: Bug
> Components: gfsh
> Affects Versions: 1.13.0
> Reporter: Dale Emery
> Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
>
> {{LogExporter}} tries to read and export any directory entry whose name is
> accepted by its log file selector predicate. The predicate accepts any entry
> whose name, when converted to lower case, contains ".log". If one of those
> entries is directory, the predicate accepts it anyway. When {{LogExporter}}
> attempts to create a {{FileReader}} read it, the {{FileReader}} constructor
> throws {{FileNotFoundException}}.
> There is a stat file selector predicate that works similarly.
> {{LogExporter}}'s log and stat file selector predicates should accept only
> files, and not directories. And perhaps the should accept only files whose
> names _end_ in the appropriate extension, rather than _containing_ the
> characters. The predicates are defined in {{LogExporter}}'s
> {{findLogFiles()}} and {{findStatFiles()}} methods.
> I discovered this defect by running {{LogExporterIntegrationTest}} on macOS.
> Each test's preparation writes some to-be-exported files into a temporary
> directory that, on macOS, may contain numerous other files and directories.
> One of those directories (e.g.
> /var/folders/yz/6y59fxln38d7lf2jxng1zgg40000gn/T/com.apple.LoginUserService),
> which matches the {{LogExporter}}'s predicate.
> These tests should also be changed to write their to-be-exported files to a
> directory that is known to be empty.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
