[
https://issues.apache.org/jira/browse/FTPSERVER-289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13777821#comment-13777821
]
latino edited comment on FTPSERVER-289 at 10/11/13 2:09 PM:
------------------------------------------------------------
file locking mechanism is required as server runs inside a single JVM: any
thread inside the JVM is allowed to write file unless you provide a lock
mechanism.
furthermore using FileLock in nio package, it's safe inter-process access, but
not inter-thread.
in the last Apache FTP Server release is possible to create more
fileOutputStream on the same local file by different session from the same user
( see NativeFTPFile class and STOR command implementation ) , e.g the old
session is attempting to close stream, while the new one is opening for write).
so we apprecciate a file lock mechanism for safety use in concurrent enviroment
was (Author: ginolatino):
file locking mechanism is required as server runs inside a single JVM: any
thread inside the JVM is allowed to write file unless you provide a lock
mechanism.
While using FileLock in nio package, you assure inter-process safe access, but
not inter-thread.
in the last Apache FTP Server release is still possible to get more
fileOutputStream open on the same file by different threads ( see NativeFTPFile
class and STOR command implementation class and consider concurrent FTPSessions
of the same user, e.g the old session is attempting to close stream, while the
new one is opening for write).
Could be appreciated a unique fileOutStream object per file?
> Implement locking mechanism for files.
> --------------------------------------
>
> Key: FTPSERVER-289
> URL: https://issues.apache.org/jira/browse/FTPSERVER-289
> Project: FtpServer
> Issue Type: New Feature
> Components: Core
> Affects Versions: 1.0.0
> Reporter: David Latorre
> Fix For: WISHLIST
>
>
> In order to solve FTPSERVER-288 , this is, to prevent the possibility of race
> conditions in STOU command ( it is possible that non-unique filenames be
> generated with the current implementation) we would eventually need that
> there was some file locking mechanism which might be a mechanism to keep
> track of in-use files.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
