This is the mail archive of the
cygwin-developers@cygwin.com
mailing list for the Cygwin project.
Re: stat matters
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