[prev in list] [next in list] [prev in thread] [next in thread] 

List:       mina-dev
Subject:    Re: FTP SERVER  -  server side file locking
From:       Darryl Miles <darryl-mailinglists () netbauds ! net>
Date:       2013-12-18 13:56:27
Message-ID: 52B1A98B.9050505 () netbauds ! net
[Download RAW message or body]

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

[prev in list] [next in list] [prev in thread] [next in thread]