From: Suresh Jayaraman <sjayaraman-l3A5Bk7waGM@public.gmane.org>
To: Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Cc: Matt Mackall <mpm-VDJrAJ4Gl5ZBDgjK7y7TUQ@public.gmane.org>,
linux-cifs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: Strange hardlink behavior with CIFS
Date: Fri, 29 Oct 2010 16:21:41 +0530 [thread overview]
Message-ID: <4CCAA73D.80009@suse.de> (raw)
In-Reply-To: <20101028074650.3e035241-9yPaYZwiELC+kQycOl6kW4xkIHaj4LzF@public.gmane.org>
On 10/28/2010 05:16 PM, Jeff Layton wrote:
> On Thu, 28 Oct 2010 16:38:28 +0530
> Suresh Jayaraman <sjayaraman-l3A5Bk7waGM@public.gmane.org> wrote:
>
>> On 10/28/2010 02:02 AM, Jeff Layton wrote:
>>> On Wed, 27 Oct 2010 12:31:26 -0500
>>> Matt Mackall <mpm-VDJrAJ4Gl5ZBDgjK7y7TUQ@public.gmane.org> wrote:
>>>
>>>> On Tue, 2010-10-19 at 15:13 +0530, Suresh Jayaraman wrote:
>>>>> On 10/19/2010 12:34 AM, Matt Mackall wrote:
>>>>>> With Linux 2.6.32-35 and either Windows or Samba in nounix mode,
>>>>>> hardlink counts can mysteriously disappear:
>>>>>>
>>>>>> - create hardlink pair foo,bar
>>>>>> - stat foo -> nlink = 2
>>>>>> - open foo
>>>>>> - stat foo -> nlink = 1
>>>>>> - close
>>>>>> - wait or sync
>>>>>> - ls -l -> nlink = 2
>>>>>>
>
> I think we ought to not have CIFSSMBOpen try to fake up values since
> it's clearly incorrect. The easiest way is just to get rid of the
> places that try to do that (like this one).
>
> If we feel that it's important to try and use the values that are
> returned from this call (and others that fake up a QPathInfo response
> like this), then they ought to changed so that they put the info into a
> cifs_fattr struct and then update the inode values from that.
>
> To do that however, you'll need to fix cifs_fattr_to_inode to only
> update the values that have been set in the cifs_fattr so that you're
> not faking up other values. That may mean adding a "valid" field of
> some sort and setting flags that show which fields should be copied to
> the inode.
>
Great idea, Thanks.
Looks like we could overload fattr->cf_flags. Something like this?
(Only compile tested as I screwed up my VM setup)
fs/cifs/cifsglob.h | 1 +
fs/cifs/cifssmb.c | 2 +-
fs/cifs/inode.c | 8 ++++++--
3 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/fs/cifs/cifsglob.h b/fs/cifs/cifsglob.h
index f259e4d..bdb508f 100644
--- a/fs/cifs/cifsglob.h
+++ b/fs/cifs/cifsglob.h
@@ -558,6 +558,7 @@ struct dfs_info3_param {
#define CIFS_FATTR_DELETE_PENDING 0x2
#define CIFS_FATTR_NEED_REVAL 0x4
#define CIFS_FATTR_INO_COLLISION 0x8
+#define CIFS_FATTR_NLINK_NOT_SET 0x10 /* number of hardlinks unknown */
struct cifs_fattr {
u32 cf_flags;
diff --git a/fs/cifs/cifssmb.c b/fs/cifs/cifssmb.c
index 2f2632b..6a5455f 100644
--- a/fs/cifs/cifssmb.c
+++ b/fs/cifs/cifssmb.c
@@ -1326,7 +1326,7 @@ openRetry:
/* the file_info buf is endian converted by caller */
pfile_info->AllocationSize = pSMBr->AllocationSize;
pfile_info->EndOfFile = pSMBr->EndOfFile;
- pfile_info->NumberOfLinks = cpu_to_le32(1);
+ pfile_info->NumberOfLinks = 0; /* not known */
pfile_info->DeletePending = 0;
}
}
diff --git a/fs/cifs/inode.c b/fs/cifs/inode.c
index 39869c3..7ab9a62 100644
--- a/fs/cifs/inode.c
+++ b/fs/cifs/inode.c
@@ -128,7 +128,8 @@ cifs_fattr_to_inode(struct inode *inode, struct cifs_fattr *fattr)
inode->i_mtime = fattr->cf_mtime;
inode->i_ctime = fattr->cf_ctime;
inode->i_rdev = fattr->cf_rdev;
- inode->i_nlink = fattr->cf_nlink;
+ if (!(fattr->cf_flags & CIFS_FATTR_NLINK_NOT_SET))
+ inode->i_nlink = fattr->cf_nlink;
inode->i_uid = fattr->cf_uid;
inode->i_gid = fattr->cf_gid;
@@ -531,7 +532,10 @@ cifs_all_info_to_fattr(struct cifs_fattr *fattr, FILE_ALL_INFO *info,
fattr->cf_mode &= ~(S_IWUGO);
}
- fattr->cf_nlink = le32_to_cpu(info->NumberOfLinks);
+ if (info->NumberOfLinks)
+ fattr->cf_nlink = le32_to_cpu(info->NumberOfLinks);
+ else
+ fattr->cf_flags |= CIFS_FATTR_NLINK_NOT_SET;
fattr->cf_uid = cifs_sb->mnt_uid;
fattr->cf_gid = cifs_sb->mnt_gid;
next prev parent reply other threads:[~2010-10-29 10:51 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-18 19:04 Strange hardlink behavior with CIFS Matt Mackall
2010-10-19 9:43 ` Suresh Jayaraman
2010-10-20 9:18 ` bjoern
[not found] ` <loom.20101020T111137-239-eS7Uydv5nfjZ+VzJOa5vwg@public.gmane.org>
2010-10-20 15:01 ` Steve French
[not found] ` <4CBD6843.3060702-l3A5Bk7waGM@public.gmane.org>
2010-10-27 17:31 ` Matt Mackall
2010-10-27 20:32 ` Jeff Layton
[not found] ` <20101027163230.28591971-9yPaYZwiELC+kQycOl6kW4xkIHaj4LzF@public.gmane.org>
2010-10-27 20:49 ` Matt Mackall
2010-10-28 11:08 ` Suresh Jayaraman
[not found] ` <4CC959AC.10301-l3A5Bk7waGM@public.gmane.org>
2010-10-28 11:46 ` Jeff Layton
[not found] ` <20101028074650.3e035241-9yPaYZwiELC+kQycOl6kW4xkIHaj4LzF@public.gmane.org>
2010-10-29 10:51 ` Suresh Jayaraman [this message]
[not found] ` <4CCAA73D.80009-l3A5Bk7waGM@public.gmane.org>
2010-10-29 11:19 ` Jeff Layton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4CCAA73D.80009@suse.de \
--to=sjayaraman-l3a5bk7wagm@public.gmane.org \
--cc=jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=linux-cifs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=mpm-VDJrAJ4Gl5ZBDgjK7y7TUQ@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox