On Fri, 2009-09-25 at 08:53 -0400, Filipe Brandenburger wrote:
> Hi,
>
> On Fri, Sep 25, 2009 at 08:07, janezkosmr <janezkosmr@xxxxxxxxx> wrote:
> > I encountered an interesting problem. We have a Java application on a samba
> > server. The folder is then shared to the clients via a samba share. So far
> > it works OK. Until now we had windows clients and everything worked OK. But
> > now we are trying to Linux clients and this is where the fun starts. When a
> > developer copies a new jar to the folder which is shared via samba. And if
> > this copying is done by scp strange things start happening. After a few
> > clicks the application stops working returning NoClassDeffFound, even if
> > the file is there and readable. After that it is not enough to just stop
> > the application, you have to unmount an then mount the share. I tried
> > turning off oplocks in the samba configuration as suggested in the samba
> > how-to, but it doesn't fix the problem.
> > Has anyone seen a similar error?
>
> I believe the problem is that you are rewriting the file on the server
> (with "scp") while it is open on the clients (using NFS? or mounted
> CIFS?). As the clients have the file open they will have parts of it
> cached, and those parts will be updated on the server but the cache
> will persist on the client for sometimes quite a long time, or until
> you unmount the network filesystem, which it seems is what you are
> currently doing to fix the issue.
>
> I would suggest that you change the procedure to update the .jar file.
> Instead of uploading the file with the same name, which will overwrite
> it, you should upload the file with a new temporary name and when the
> transfer is finished rename the file to its definitive name (which
> will effectively replace the old file which will then be deleted).
> That way the file has the same name but a new i-node (in effect it's a
> different file). Clients that had the old file open will still be
> using it until they're done with it. Clients that read the new file at
> that point will get the new i-node number and any cache they had for
> the old file will not be used as it's for a different i-node.
>
> I don't think you can upload files like this with scp, but I'm almost
> sure you can do it with "sftp" where you have a more complete command
> language including a "put" command that allows a different name at the
> remote side and a "rename" command to change the file name once the
> upload is finished. You can script the transfer with something like:
>
> sftp myserver.example.com <<!
> put $localfilename $remotetmpname
> rename $remotetmpname $remotefinalname
> !
------
Or if that does not work Push the files to the server through CIFS if on
a local LAN. It could maybe the Devs machine has a lock on the file
still, just maybe?
John
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
