bug-sed
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#27269: Sed --in-place is messing NTFS file permissions


From: Jim Meyering
Subject: bug#27269: Sed --in-place is messing NTFS file permissions
Date: Thu, 16 Nov 2017 22:22:40 -0800

On Wed, Nov 15, 2017 at 2:43 AM, Assaf Gordon <address@hidden> wrote:
...
> 3.
> If ACL support is compiled in sed, using "--in-place"
> leads to the following syscalls:
>
>   fchown(4, 1000, 1000)                   = 0
>   fgetxattr(3, "system.posix_acl_access", "", 132) = 0
>   fstat(3, {st_mode=S_IFREG|0664, st_size=6, ...}) = 0
>   fsetxattr(4, "system.posix_acl_access", "\2\0\0\0\37....", 28, 0) = 0
>   close(3)                                = 0
>   close(4)                                = 0
>   rename("world", "world.bak")            = 0
>   rename("./sedcrOmKi", "world")          = 0
>
> 4.
> If ACL support is not compiled in sed, using "--in-place"
> leads to the following syscalls:
>
>   fchown(4, 1000, 1000)                   = 0
>   fchmod(4, 0100664)                      = 0
>   close(3)                                = 0
>   close(4)                                = 0
>   rename("world", "world.bak")            = 0
>   rename("./sednDUqpF", "world")          = 0
>
>
> One can perhaps infer that fsetxattr/fgetxattr do not work on NTFS
> mounts, but also don't fail with ENOTSUP.
...
> Is this a bug?
> and if so, is it in sed or gnulib or libacl ?
> Not sure about this.

Hi Assaf,
Thank you for the thorough analysis.
Following your instructions in https://debbugs.gnu.org/27269#8, I
reproduced the failure on Fedora 26 with Linux 4.13.12.
That looks like either we're somehow telling f[gs]etxattr to do the
wrong thing, or it's a bug that they fail to do what we want, yet they
return 0/success.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]