thanks Darryl, very helpful and clear reply. i was looking for an answer for a long, long time. but i still can't understand how to implement a "single uploader" requirement : i suppose the uploader client sends a STORE command with a unique filename ( i.e. storing my_filename.txt as my_filename.txt.123456); at the end of transfer, either completed or partial, the client sends a RENAME command ( to my_filename.txt ). Is it right? if two uploaders are running concurrently, the concurrent RENAME command executions are ordered ? are executed in atomic way? and if a second client asks for information about the file (i.e. sending a SIZE command) while the first one is executing RENAME, what happens ? ( consider case of concurrent executions of RENAME and MSLD). the rename method fo java.io.File classs does not ensure atomicity , as well as javadocs says "The rename operation might not be able to move a file from one filesystem to another, it might not be atomic, and it might not succeed if a file with the destination abstract pathname already exists. The return value should always be checked to make sure that the rename operation was successful" the scenario i'm working about is the upload of big size files with slow connections; so it's likely several attempts for transfer the full file.And it's not desiderable delete partial file before renaming it, because if rename fail i lose the file and i should restart the transfer from the beginnning thanks in advance. ivo ----Messaggio originale---- Da: [email protected] Data: 18-dic-2013 15.00 A: "ivo"<[email protected]> Ogg: Re: FTP SERVER - server side file locking ivo wrote: > as well know, fileoutputstream and randomaccessfile objects aren't thread > safe.So i if concurrent client sessions upload the same file concurrently ( > e.g. while restarting a previous interrupted upload or malicious use as > client starting more uploads of the same file), the received file could have > wrong data as different streams are writing on the same file concurrently.is > it right or implementation ensure consistent received file content? Yes they FileOutputStream/RandomAccessFile are thread safe (for different Java object handles on the same file - which is the use case you talk of right, each client has their own Java object handle). This is also true for FTP applications written in C language. Since multiple Unix file descriptors can be open on the same file at the same time. Each FD can do its own thing in relation to making concurrent and overlapping system calls against each FD. In fact FDs themselves a fully thread-safe in respect of the kernel API, you can not break the kernel. So the problem here has nothing to do with your thoughts on "thread safety". What you want is the FTP application to enforce access restrictions to the file when there is a user modifying the data (i.e. an application imposed limitation, because the Kernel and Java language have no problems with overlapping read/write access). Usually with FTP users always upload files to a different filename like my-new-file.tmp and rename the file in the next command (after the STOR) once the client considers the upload completed and successful to my-new-file.txt. Any downloaders only look for *.txt files and ignore *.tmp in the directory listings they see. Now you have an atomic way to replace the file, it is either complete or the old version. And there is no need to provide any locking at the FTP server to manage concurrent users and modifications to the data. While the upload is taking place, all downloaders can still access the old version of the file since the renamed unchanged. If you have a requirement to ensure that once an uploader has started to upload that no download sees the old file, nor partial file, then you have the uploading client rename away or delete the existing file before sending the STOR command. Now on Windows things can be different. By default it has limitations on being able to delete a file that has one or more file handles open to it. Recent versions of Windows have an option to allow this but it is not the default which follows the poor historic choice they made back from Win98. Darryl If you reply to this email, your message will be added to the discussion below: http://apache-mina.10907.n7.nabble.com/FTP-SERVER-server-side-file-locking-tp40241p40757.html To unsubscribe from FTP SERVER - server side file locking, click here. NAML -- View this message in context: http://apache-mina.10907.n7.nabble.com/R-Re-FTP-SERVER-server-side-file-locking-tp40930.html Sent from the Apache MINA Developer Forum mailing list archive at Nabble.com.
