于 2013年12月15日 21:13, Jean-Pierre André 写道:
> Hi again,
>
> See below.
>
> Regards
>
> Jean-Pierre
>
> Zorro Lang wrote:
>> 于 2013年12月15日 19:26, Jean-Pierre André 写道:
>>> Hi,
>>>
>>> It still was buggy, please try the one attached....
>>>
>>> Regards
>>>
>>> Jean-Pierre
>>>
>>>
>> Hi, I just wanted to send email to you. I just saw the code, I think
>> the line-159 and line-171 in tests/chown/00.t will run failed in
>> linux:xfs.
>> 157 expect 0 -u 65534 -g 65533,65532 chown ${n0} 65534 65532
>> 158 case "${os}:${fs}" in
>> 159 Linux:*)
>> 160 expect 06555,65534,65532 lstat ${n0} mode,uid,gid
>> 161 ;;
>> 162 *)
>> 163 expect 0555,65534,65532 lstat ${n0} mode,uid,gid
>> 164 ;;
>> 165 esac
>> 166 expect 0 chmod ${n0} 06555
>> 167 expect 06555 lstat ${n0} mode
>> 168 expect 0 -u 65534 -g 65533,65532 -- chown ${n0} -1 65533
>> 169 case "${os}:${fs}" in
>> 170 Linux:*)
>> 171 expect 06555,65534,65533 lstat ${n0} mode,uid,gid
>> 172 ;;
>> 173 *)
>> 174 expect 0555,65534,65533 lstat ${n0} mode,uid,gid
>> 175 ;;
>> 176 esac
>>
>> The Ext fs will not clear the SUID and SGID bits after chown a
>> directory.
>
> Yes, and same for btrfs.
>
>>
>> The VFS only requests clearing it if it's not a directory, in
>> chown_common() upstream:
>>
>> if (!S_ISDIR(inode->i_mode))
>> newattrs.ia_valid |=
>> ATTR_KILL_SUID | ATTR_KILL_SGID |
>> ATTR_KILL_PRIV;
>>
>> But xfs always clear it by himself:
>> in xfs_setattr_nonsize() upstream:
>>
>> /*
>> * Change file ownership. Must be the owner or privileged.
>> */
>> if (mask & (ATTR_UID|ATTR_GID)) {
>> /*
>> * CAP_FSETID overrides the following restrictions:
>> *
>> * The set-user-ID and set-group-ID bits of a file
>> will be
>> * cleared upon successful return from chown()
>> */
>> if ((ip->i_d.di_mode & (S_ISUID|S_ISGID)) &&
>> !capable(CAP_FSETID))
>> ip->i_d.di_mode &= ~(S_ISUID|S_ISGID);
>>
>>
>> So you should not just use Linux:* to judge it.
>>
>> Actually glusterfs not clear it now, but I reported it as a bug to
>> glusterfs developers, because one glusterfs developer said glusterfs
>> should as same as xfs, when I use xfs backend to be the glusterfs
>> server.
>> So after the glusterfs developers checked the bug, they will give a
>> assured answer.
>>
>> Others I test passed for glusterfs and xfs.
>>
>> Wait for your new modification:)
>
> I had changes of mind with this one, but now, I think
> that the behavior common to ext3, ext4 and btrfs
> should be considered as the normal behavior on
> Linux, and xfs considered as a variant.
>
> On Solaris zfs and ufs, the bits are cleared.
>
> Now, depending on glusterfs position on this
> subject, this should be :
>
> either (if glusterfs wants to behave like ext3)
>
> Linux:xfs|Linux:glusterfs)
> expect 0555,65534,65532 lstat ${n0} mode,uid,gid
> ;;
> Linux:*)
> expect 06555,65534,65532 lstat ${n0} mode,uid,gid
> ;;
> *)
> expect 0555,65534,65532 lstat ${n0} mode,uid,gid
> ;;
> esac
>
> or (if glusterfs wants to behave like xfs)
>
> Linux:xfs|Linux:glusterfs)
> expect 0555,65534,65532 lstat ${n0} mode,uid,gid
> ;;
> Linux:*)
> expect 06555,65534,65532 lstat ${n0} mode,uid,gid
> ;;
> *)
> expect 0555,65534,65532 lstat ${n0} mode,uid,gid
> ;;
> esac
>
> I am waiting for your expected reply from the glusterfs
> team to make a choice.
>
Hi,
I have talked about it with glusterfs developer, the expected result is
depend on the backend fs of glusterfs. So the suggestion is don't test
this case for glusterfs, if must test, the most possible result for
glusterfs is "expect 06555,65534,65532 lstat ${n0} mode,uid,gid".
But ...
Because the glusterd run with root in gluster server, so the chown
operation is did by root in gluster server. But the posix didn't specify
whether the bits also should be cleared when root does the chown(), in
the Linux the behavior depends on the kernel version. So I suggest that
glusterfs don't test this case.
What do you think?
Thank you,
Zorro Lang
>
>>
>> Thank you,
>> Zorro Lang
>>
>>> Jean-Pierre André wrote:
>>>> Hi again,
>>>>
>>>> Hopefully, the attached file is the correct one.
>>>>
>>>> Sorry for the confusion.
>>>>
>>>> Regards
>>>>
>>>> Jean-Pierre
>>>>
>>>>
>>>> Jean-Pierre André wrote:
>>>>> Hi,
>>>>>
>>>>> Today, I have made the change I was suggesting, and
>>>>> tested again all the file systems I could gather :
>>>>>
>>>>> On Linux : ext3, ext4, xfs, btrfs, ntfs-3g
>>>>> on OpenIndiana (SunOS) : ZFS, UFS, ntfs-3g
>>>>>
>>>>> All of them pass with no error. I just discovered two
>>>>> unexpected (but correct) behaviors in link/00.t on
>>>>> UFS (fixed now).
>>>>>
>>>>> The changed files are attached, can you make a
>>>>> new try on glusterfs, just to be sure I have forgotten
>>>>> nothing ?
>>>>>
>>>>> See also my comments below.
>>>>>
>>>>> Thanks again for your collaboration.
>>>>>
>>>>> Regards
>>>>>
>>>>> Jean-Pierre
>>>>>
>>>>> Zorro Lang wrote:
>>>>>> 于 2013年12月14日 01:51, Jean-Pierre André 写道:
>>>>>>> Hi,
>>>>>>>
>>>>>>> Zorro Lang wrote:
>>>>>>>> 于 2013年12月13日 16:17, Jean-Pierre André 写道:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> Thanks for the proposed patches.
>>>>>>>>>
>>>>>>>>> What are the situations where glusterfs should not behave
>>>>>>>>> like ext3/ext4 on Linux ?
>>>>>>>> The posix is a standard, GNU/Linux follow this standard, so the
>>>>>>>> filesystem in linux should have same behavior. The glusterfs
>>>>>>>> nearly no difference with other fs, but there are still to
>>>>>>>> things I need to do:
>>>>>>>
>>>>>>> [...]
>>>>>>>
>>>>>>> Actually, what I meant, is that in all the situations where
>>>>>>> you made changes, glusterfs behaves the same as ext3
>>>>>>> and xfs on Linux.
>>>>>>>
>>>>>> Oh, I think I have explained all the situations where I made
>>>>>> changes on last email.
>>>>>>> And there are known cases where Solaris file systems or
>>>>>>> freebsd ones behave differently from Linux ones.
>>>>>>>
>>>>>>> So you end up enumerating all file systems, like below.
>>>>>>> This hides what is specific to an operating system and
>>>>>>> would require to add cases for ext4 or newer file
>>>>>>> systems.
>>>>>>>
>>>>>>>>>> case "${os}:${fs}" in
>>>>>>>>>> -Linux:ext3)
>>>>>>>>>> +Linux:ext3 | Linux:xfs | Linux:glusterfs)
>>>>>>>>>> test_check $ctime1 -lt $ctime2
>>>>>>>>>> ;;
>>>>>>>>>> -*)
>>>>>>>>>> +*:ext3 | *:xfs | *:ZFS | *:ntfs-3g | *:UFS)
>>>>>>>>>> test_check $ctime1 -eq $ctime2
>>>>>>>>>> + ;;
>>>>>>>>>> +*)
>>>>>>>>>> + test_check $ctime1 -le $ctime2
>>>>>>>>>> ;;
>>>>>>>>>> esac
>>>>>>>
>>>>>> The ctime changed by linux VFS, so all linux local filesystem
>>>>>> must update the ctime. But some fs with FUSE maybe update or not
>>>>>> update the ctime.
>>>>>
>>>>> Actually not, I have checked again. Fuse does not
>>>>> call the file system when uid == gid == -1, so the
>>>>> file system cannot update the ctime.
>>>>>
>>>>>> I haven't test UFS, ZFS and ntfs-3g in Linux, I just knew xfs,ext
>>>>>> and glusterfs will use "$ctime1 -lt $ctime2" in linux, and I have
>>>>>> made sure that by ask the ext, xfs and glusterfs developer.
>>>>>> The original code is:
>>>>>> "test_check $ctime1 -eq $ctime2 "
>>>>>> So I think all of the $os:$fs which the pjd-fstest supported(in
>>>>>> README) will not update the ctime previously. Now I just made
>>>>>> sure the ext, xfs, glusterfs in linux, so I just wrote
>>>>>> "+Linux:ext3 | Linux:xfs | Linux:glusterfs)
>>>>>> test_check $ctime1 -lt $ctime2 "
>>>>>> at first.
>>>>>> Then I want to keep other situations to use "-eq".
>>>>>> Last I use "-le" to delegate "need not" which posix said for
>>>>>> others "unclear" situations.
>>>>>
>>>>> Yes, your proposal is correct, but it can be simplified
>>>>> to make it easier to maintain.
>>>>>
>>>>>
>>>>>>
>>>>>>> So I would suggest writing the above like
>>>>>>>
>>>>>>> case "${os}:${fs}" in
>>>>>>> Linux:glusterfs)
>>>>>>> # test for glusterfs if it is different from most Linux ones,
>>>>>>> ;;
>>>>>> the linux:glusterfs not need to be wrote specifically, it's same
>>>>>> with ext3 and xfs in linux. If others fs different from most
>>>>>> linux ones, it can be wrote here.
>>>>>
>>>>> Yes of course. What I wrote above was a generic
>>>>> pattern to be adapted to each specific case.
>>>>>
>>>>>>> Linux:*)
>>>>>>> # usual test for Linux ones (ext3, ext4, and usually glusterfs)
>>>>>>> ;;
>>>>>>> # specific tests here for other OS when needed
>>>>>>> *)
>>>>>>> # tests not applicable to Linux
>>>>>>> ;;
>>>>>>> esac
>>>>>>>
>>>>>>
>>>>>>> Advantages :
>>>>>>> - glusterfs would probably not be a special case
>>>>>>> - special situations for some OS or fs are taken into
>>>>>>> account
>>>>>>> - no update is needed for newer file systems (e.g. ext4)
>>>>>> when I tested ext4 I often use fs=ext3, and test passed :)
>>>>>
>>>>> I confirm this. Same for btrfs.
>>>>>
>>>>>>> - file systems, like ntfs-3g, whose behavior depends
>>>>>>> on the OS are easily taken into account
>>>>>>> - changes in behavior of a file system can be detected
>>>>>>> (and your tests showed a change in ext3 behavior
>>>>>>> which may have to be propagated to other file systems)
>>>>>> I think maybe we should test all "unclear" situations in all the
>>>>>> $os:$fs which the pjd-fstest support(in README or tests/conf), to
>>>>>> make sure the current status of every $os:$fs, before public the
>>>>>> newest code.
>>>>>
>>>>> I think I have tested all these cases, and found another
>>>>> unclear one : when a hard link is unsuccessful, UFS does
>>>>> not update the ctime, but all other file systems do, and
>>>>> Posix does not mention ctime on unsuccessful completion.
>>>>>
>>>>>>>
>>>>>>> I cannot do this change now, I will make a proposal
>>>>>>> later.
>>>>>> OK, I have given you my thinking here, I think you can decide how
>>>>>> to do the final modification:) If need me to do something I will
>>>>>> try my best:)
>>>>>>
>>>>>> Thank you,
>>>>>> Zorro Lang
>>>>>>>
>>>>>>> Regards
>>>>>>>
>>>>>>> Jean-Pierre
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>>
>
>
------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
ntfs-3g-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ntfs-3g-devel
