That's true. But consider following conditions, 1. Copy one "1 GB" file to nfs share using command "cp". While cp is progressing try deleting that file from CIFS share. 2. Copy one "1 GB" file to CIFS share using "Drag n Drop". While copy is progressing try deleting that file from NFS share What I would expect in these scenarios is "user should not be able to delete the file under copying". I assume linux "cp" implementation will not lock a file under copying (At least I didn't see any fcntl / flock calls on tracing cp). So I assume this is quite normal in Linux environment (file in use at one place can be deleted from another shell). But in a mixed environment windows client will expect an open file to be protected from being deleted. Is it possible to achieve this?. Thanks Anoop > -----Original Message----- > From: Jeff Layton [mailto:jlayton@xxxxxxxxxx] > Sent: Wednesday, May 20, 2009 10:17 PM > To: Anoop P.A. > Cc: linux-nfs@xxxxxxxxxxxxxxx > Subject: Re: NFS-CIFS locking > > On Wed, 20 May 2009 09:38:21 -0700 > "Anoop P.A." <Anoop_P.A@xxxxxxxxxxxxxx> wrote: > > > Hi Jeff, > > > > Thanks much for your inputs. > > > > I have tried to get some info from samba list but no luck. > > > > My proposed system is a fileserver which is supposed to be share point > > for both windows and Linux ( CIFS and NFS). So I can't point one > > particular application. Basically I want to rule out file corruption > > while sharing single file across multiple protocols. > > > > That's a very different situation than what you originally asked. You > asked about cross-protocol locking. That's achievable, but it depends > on using applications that actually do lock the files and some > understanding about what you get when you lock the files in this way. > > If you don't have well-behaved apps that lock files to guard against > concurrent access, then you'll have problems even if you're not using > NFS and samba together. > > -- > Jeff Layton <jlayton@xxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
