mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ivo <seventy...@virgilio.it>
Subject R: Re: FTP SERVER - server side file locking
Date Fri, 17 Jan 2014 11:42:59 GMT



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: ml-node+s10907n40757h96@n7.nabble.com

Data: 18-dic-2013 15.00

A: "ivo"<seventyboy@virgilio.it>

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.
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message