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