stat matters

Christopher Faylor cgf@redhat.com
Fri May 30 13:44:00 GMT 2003


On Thu, May 29, 2003 at 11:05:00PM -0400, Pierre A. Humblet wrote:
>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.

Correct.  They will be marked as "don't open the file to check for
executable".  If there was an actual "don't care" state, I would have
used that.

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

If we do that, then the function name 'has_acls' should change.  It
would no longer reflect the meaning of the function.

>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 ?

Because the filesystem flags have only been in pc for a couple of days?

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

Lets wait until the next version for this.  The stuff in my sandbox
exports a path_conv into every fhandler, so the duplication is easy to
remove.

cgf



More information about the Cygwin-developers mailing list