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.
>
> 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
