Maybe not exactly what you are experiencing, but I have experienced many strange CIFS issues from both CentOS and Windows systems communicating via wired ethernet.
I found specifically that there is a known issue between Windows Server 2003 and CentOS/Linux 5.x because of incompatibilities produced as a result of how M$ implements CIFS in the kernel. Microsoft will not address this according to what I read. I stumbled across this while trying to mount a Windows managed storage server from a CentOS server running Bacula. I auto-mounted the remote Windows share in fstab no problem but when transferring a lot of files or large files it crashed the Linux kernel on the CentOS running the Bacula Director. The fix was the run a remote storage system as CentOS. No more CIFS required. Funny how when Windows was removed from the formula there were no more problems. :-) Not sure this helps your exact sitch.
Larry Kemp
Network Engineer
U.S. Metropolitan Telecom, LLC
Address: 24017 Production Circle Bonita Springs, FL 34135
Adtran ASP/ATSA Internetworking, ASP/ATSA IP Telephony, ASP/ATSA Wireless
-----Original Message-----
From: centos-bounces@xxxxxxxxxx [mailto:centos-bounces@xxxxxxxxxx] On Behalf Of JohnS
Sent: Friday, September 25, 2009 10:19 AM
To: CentOS mailing list
Subject: Re: samba file locking
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
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
