samba - Mar 2005 - problem when writing to a deleted file

I've got a weird situation. I have an RMI application that is creating 
PDF's for a web server. A request comes in to the web server, the web 
server deletes the PDF if it exists and then requests an RMI server to 
create the PDF. The PDF is written directly to the web server's disk via 
a Samba mount (both systems are Linux and are running Samba 3.0.10). The 
problem occurs when the web server serves 2 almost simultaneous requests 
for the same PDF. The first request deletes (if necessary) the existing 
PDF and calls the RMI server to create a new PDF. The next request 
deletes the PDF (that is now being created by the RMI server) and calls 
the RMI server to create a new PDF. The first RMI process can no longer 
write to the PDF and the second process can't write to it either. It's 
very much a timing issue. If the requests are spread out just enough, 
then no one's the wiser.

Samba generates the following error (from messages). I believe that 
means that Samba is getting an EBADF error (bad file number).

    kernel: smb_writepage_sync: failed write, wsize=4096, result=-9

What exactly is going on in the file system during this? I know what 
happens in a normal UNIX file system (and the problem does not occur 
there). I am going to write a test application that creates just plain 
files without using the PDF library to see if perhaps they do something 
funny or if it's just how Samba handles deleted files. I have a call 
into the writers of the PDF library as well.

This seems like a silly problem and we'll probably have to code around 
it anyway, but something is not working correctly (in my eye).

Thanks,
Simon

I just tested it without using the PDF library and (luckily) got similar 
results. This time, however, I got a "Text file busy" Exception (java)
while the first thread was writing. The second thread continued writing 
to the new file.

Simon

Simon Weatherill wrote:
> I've got a weird situation. I have an RMI application that is creating 
> PDF's for a web server. A request comes in to the web server, the web 
> server deletes the PDF if it exists and then requests an RMI server to 
> create the PDF. The PDF is written directly to the web server's disk 
> via a Samba mount (both systems are Linux and are running Samba 
> 3.0.10). The problem occurs when the web server serves 2 almost 
> simultaneous requests for the same PDF. The first request deletes (if 
> necessary) the existing PDF and calls the RMI server to create a new 
> PDF. The next request deletes the PDF (that is now being created by 
> the RMI server) and calls the RMI server to create a new PDF. The 
> first RMI process can no longer write to the PDF and the second 
> process can't write to it either. It's very much a timing issue. If
> the requests are spread out just enough, then no one's the wiser.
>
> Samba generates the following error (from messages). I believe that 
> means that Samba is getting an EBADF error (bad file number).
>
>    kernel: smb_writepage_sync: failed write, wsize=4096, result=-9
>
> What exactly is going on in the file system during this? I know what 
> happens in a normal UNIX file system (and the problem does not occur 
> there). I am going to write a test application that creates just plain 
> files without using the PDF library to see if perhaps they do 
> something funny or if it's just how Samba handles deleted files. I 
> have a call into the writers of the PDF library as well.
>
> This seems like a silly problem and we'll probably have to code around 
> it anyway, but something is not working correctly (in my eye).
>
> Thanks,
> Simon

-- 
Simon Weatherill
office phone: 603-863-4111
cell phone: 603-359-1071

===================================================This communication (including
any attachments) is intended for the use
of the intended recipient(s) only and may contain information that
is confidential, privileged or legally protected.  Any unauthorized
use or dissemination of this communication is strictly prohibited.
If you have received this communication in error, please immediately
notify the sender by return e-mail message and delete all copies of the
original communication.  Thank you for your cooperation.