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: >>> On Jan 27 13:21, Ken Brown wrote: >>>> Ken Brown (3): >>>> Cygwin: fhandler_base::fstat_fs: accomodate the O_PATH flag >>>> Cygwin: fhandler_disk_file::fstatvfs: refactor >>>> Cygwin: FIFO::fstatvfs: use our handle if O_PATH is set >>>> >>>> winsup/cygwin/fhandler.h | 1 + >>>> winsup/cygwin/fhandler_disk_file.cc | 24 +++++++++++++++++------- >>>> winsup/cygwin/fhandler_fifo.cc | 8 ++++++++ >>>> 3 files changed, 26 insertions(+), 7 deletions(-) >>>> >>>> -- >>>> 2.21.0 >>> >>> Patches are looking good to me. >> >> OK, I'll push them. >> >>> 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? > > In both cases I don't immediately see a connection with the permissions > problem, > but it seems inefficient and makes the code confusing. I might well be > missing > something, however. > > Ken >