From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754458Ab3JVSqL (ORCPT ); Tue, 22 Oct 2013 14:46:11 -0400 Received: from mail-pd0-f171.google.com ([209.85.192.171]:64254 "EHLO mail-pd0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753663Ab3JVSqJ (ORCPT ); Tue, 22 Oct 2013 14:46:09 -0400 MIME-Version: 1.0 In-Reply-To: References: Date: Tue, 22 Oct 2013 13:46:08 -0500 Message-ID: Subject: Fwd: 3.11+ Problem with cifs links, bisected From: Steve French To: LKML , "linux-cifs@vger.kernel.org" Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org ---------- Forwarded message ---------- From: Steve French Date: Tue, Oct 22, 2013 at 1:45 PM Subject: Re: 3.11+ Problem with cifs links, bisected To: Joao Correia Cc: LKML , Pavel Shilovsky , Jeff Layton I wonder if this is a similar issue to what I fixed with (Pavel's patch assumed that these reparse points were NTFS symlinks but they could be other types of reparse points such as the new "NFS symlink" format) commit c31f330719b7331b2112a5525fe5941a99ac223d Author: Steve French Date: Sat Sep 28 18:24:12 2013 -0500 do not treat non-symlink reparse points as valid symlinks Windows 8 and later can create NFS symlinks (within reparse points) which we were assuming were normal NTFS symlinks and thus reporting corrupt paths for. Add check for reparse points to make sure that they really are normal symlinks before we try to parse the pathname. We also should not be parsing other types of reparse points (DFS junctions etc) as if they were a symlink so return EOPNOTSUPP on those. Also fix endian errors (we were not parsing symlink lengths as little endian). This fixes commit d244bf2dfbebfded05f494ffd53659fa7b1e32c1 which implemented follow link for non-Unix CIFS mounts CC: Stable Reviewed-by: Andrew Bartlett Signed-off-by: Steve French On Tue, Oct 22, 2013 at 8:12 AM, Joao Correia wrote: > > Hello list > > I've been having a problem mounting windows shares with deduplicated > files (from windows 2012 deduplication), as they would show up either > garbled or 'ls' would complain it couldn't follow them. > > Git bisect blames the following: > commit b42bf88828cde60772dc08201d0a4f1a0663d7bc > CIFS: Implement follow_link for SMB2 > Author: Pavel Shilovsky > > dmesg doesn't complain at all. > > Reverting the commit fixes the problem and the deduplicated files can > be opened perfectly, but more recent updates have been made on top of > that one and i think it can't be cleanly reverted on current -next > trees (or rcs) > > If i'm not mistaken, windows 2012 treats deduplicated files as links, > but that's just what i can surmise from using it, i haven't read > anything about it's internals yet. > > I've CC'ed the persons mentioned on the patch, please forward it to > anyone else that might be interested and is not on the lkml. > > Thanks, > Joao Correia -- Thanks, Steve -- Thanks, Steve