On 1/29/2020 9:22 AM, Corinna Vinschen wrote:
On Jan 29 10:52, Corinna Vinschen wrote:
On Jan 29 03:08, Ken Brown wrote:
On 1/28/2020 3:48 PM, Ken Brown wrote:
On 1/28/2020 2:01 PM, Ken Brown wrote:
On 1/28/2020 12:06 PM, Corinna Vinschen wrote:
As outlined on IRC, I found a problem with the ACLs created on new
FIFOs and frixed that (I think). However, Cygwin doesn't actually
return the real permissions in stat(), only the constant perms 0666,
kind of like for symlinks. I didn't have time to look into that yet,
but it would be great if we could fix that, too.
I'll take a look if you don't get to it first.
Two quick thoughts, and then I won't have time to think about this any more
until tomorrow:
First, I wonder why in fstat_fs we're not using the stat handle (i.e.,
pc.handle()).
Ignore this. I was confused.
Second, in the call to get_file_attribute in fstat_helper
(fhandler_disk_file.cc:478), why do we set the first argument to NULL instead of
using our handle?
The handle is a pipe handle, not the file handle, and the permissions
on the pipe handle were not reflecting the permissions on the file.
The NULL pointer was trying to make sure that the file gets opened
for fetching the security descriptor in get_file_sd().
I pushed a fix for the permission problem, but I didn't touch the
get_file_attribute() call in fstat_helper. If you think this can
be further streamlined, go ahead.
AFAICT, the handle returned by get_stat_handle() should always be pc.handle(),
not a pipe handle. Patch on the way.
Ken
