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