This is the mail archive of the cygwin-developers@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: stat matters


At 05:25 PM 5/29/2003 -0400, Christopher Faylor wrote:
>On Wed, May 28, 2003 at 11:33:29PM -0400, Christopher Faylor wrote:
>>>2) There is a comment in fhandler_disk_file::fstat to the effect that a 
>>>   "query open" is much faster than a normal open.
>>>   So, why don't we do a query open when possible, i.e. also for dirs,
sockets,
>>>   symlinks, and more importantly, whenever has_acls(), ntsec and
>>>   wincap.has_security () are true?
>>
>>This is supposed to be caught for anything which opens a file like
>>sockets or symlinks.  The other cases are not caught, though.  I'll add
>>something to path.cc to handle this.
>
>Which I've done.
>
>This patch pulled over some other ongoing work from my sandbox but hopefully
>it will be harmless.
>
>cgf

Thanks, Chris.

I can't test the patch now, but it looks like all files on FAT 
will be marked NOTEXEC if ntsec is on.

Also you gave me an idea. If you consider ntsec in path.cc, I would 
propose centralizing the acl related detection algorithm there.

Currently pc.has_acls() has two meanings:
For remote drives it reflects the filesystem having acls and
the value of smbntsec.
For local drives, it's only the filesystem having acls.

I suggest that pc.has_acls should take everything into account:
the file system, ntsec, smbntsec, remote/local drives and 
wincap.has_security (but not ntea). Once that's done, files that 
"pc.have_acls ()" could be opened no_query for fstat and we could 
simplify about 20 other spots in Cygwin, which all end up doing the
same detection thing.

In addition pc->has_acls() is used in fstat_helper() to determine
the inode algorithm, which means that it could be influenced by
smbntsec. Why not use the filesystem flags directly, they are
in pc ?

There is also a FH_HASACLS flag and an "has_acls" in fhandler.h
AFAICS it's used only twice: once in fhandler::open, where
pc->has_acls() is available anyway, and once in 
fhandler_disk_file::open, where it could be replaced by 0.
So it's a candidate for extinction.

Comments? I am ready to help.

Pierre


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]