[
https://issues.apache.org/jira/browse/VFS-833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17703793#comment-17703793
]
Bernd Eckenfels commented on VFS-833:
-------------------------------------
Thanks for the report. Can you give an example when this actually happens -
I.e. who changes why fs options. This does not really work very well since they
are part of the Idendity of a filesystem instance. So I would say most of the
time they have to be immutable. At least this is what VFS assumes why it does
not synchronize. Maybe it’s enough if we do a defensive copy?
> org.apache.commons.vfs2.FileSystemOptions#options is not synchronized
> ---------------------------------------------------------------------
>
> Key: VFS-833
> URL: https://issues.apache.org/jira/browse/VFS-833
> Project: Commons VFS
> Issue Type: Bug
> Affects Versions: 2.9.0
> Reporter: Kannan Ramamoorthy
> Priority: Major
>
> *Problem:*
> The map `org.apache.commons.vfs2.FileSystemOptions#options` is TreeMap. The
> datastructure is not thread-safe and resulting in situations like
> [this|https://ivoanjo.me/blog/2018/07/21/writing-to-a-java-treemap-concurrently-can-lead-to-an-infinite-loop-during-reads/]
> when used in multithreaded environments.
> *Workaround:*
> As a workaround, we have to synchronize the `FileSystemOptions` in all the
> places of the code.
> *Solution:*
> * If there is no issue, the constructor `
> protected FileSystemOptions(Map<FileSystemOptionKey, Object> options)` can be
> made public, so that users will have an option to pass a synchronized map
> when they have to. * Or, wrap the `TreeMap` instance with
> `java.util.Collections#synchronizedMap`, ensuring thread safety at the core.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
