[linux-cifs-client] Re: [PATCH] cifs: fix renaming one hardlink on top of another

[Steve French]

On Mon, Nov 3, 2008 at 9:23 AM, Jeff Layton <jlayton at redhat.com> wrote:
> On Mon, 3 Nov 2008 09:12:53 -0600
> "Steve French" <smfrench at gmail.com> wrote:
>
>> This fix looks right ... unfortunately the old code (2.6.27 and
>> earlier) had a similar bug, it looks like it returned EEXIST for this
>> case.
>>
>> What are you using to test this - the mv command does not obey posix
>> semantics (does not call rename in vfs) and I am not convinced that
>> the rename command does either.
>>
>
> I noticed it because the nfsidem test in connectathon failed (the
> rename() failed with -EEXIST).
>
> I don't think the older code failed this in most cases though. As long
> as the last CIFSSMBUnixQPathInfo call worked, then we'll return 0 on
> the old code in this case.
>
> The reason this broke now is that we changed cifs_rename to use a tmprc
> variable to hold the return code of the CIFSSMBUnixQPathInfo call in

Yes - you are right, I missed that we changed how the rc (EEXIST) got
overwritten

We really need to build a simpler set of posix fs tests ... than the
connectathon special cases so we can make this testing easier to
read/debug.   Wish the ltp fs group was more active


-- 
Thanks,

Steve