From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Xin Zhao" Subject: Urgent help needed on an NFS question, please help!!! Date: Thu, 10 Aug 2006 01:04:27 -0400 Message-ID: <4ae3c140608092204n1c07152k52010a10e209bb77@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: linux-fsdevel@vger.kernel.org Return-path: Received: from py-out-1112.google.com ([64.233.166.178]:33465 "EHLO py-out-1112.google.com") by vger.kernel.org with ESMTP id S1161027AbWHJFE2 (ORCPT ); Thu, 10 Aug 2006 01:04:28 -0400 Received: by py-out-1112.google.com with SMTP id z74so666283pyg for ; Wed, 09 Aug 2006 22:04:27 -0700 (PDT) To: linux-kernel Content-Disposition: inline Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org I just ran into a problem about NFS. It might be a fundmental problem of my current work. So please help! I am wondering how NFS guarantees a client didn't get wrong file attributes. Consider the following scenario: Suppose we have an NFS server S and two clients C1 and C2. Now C1 needs to access the file attributes of file X, it first does lookup() to get the file handle of file X. After C1 gets X's file handle and before C1 issues the getattr() request, C2 cuts in. Now C2 deletes file X and creates a new file X1, which has different name but the same inode number and device ID as the nonexistent file X. When C1 issues getattr() with the old file handle, it may get file attribute on wrong file X1. Is this true? If not, how NFS avoid this problem? Please direct me to the code that verifies this. Many many thanks! -x