于 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.
OK, although you write two same code above, I can understand what you mean:)
I will try to contact them tommorrow or after tommorrow, I still have
some questions want to ask them.
I will reply to you as soon as I can:)
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
