Re: Why does (stat() ?) open files ?

[Ben RUBSON <ben dot rubson at gmail dot com>]

On 09 Apr 2018 12:52, Corinna Vinschen wrote:

> On Apr  9 12:28, Ben RUBSON wrote:
> > Hi,
> >
> > This follows the "Why does readdir() open files ?" discussion we had a few
> > days ago.
> > Thank you Corinna for your answers and suport there !
> >
> > So, context is Cygwin, especially rsync, working over a Fuse FS.
> > This Fuse FS is assumed to be mounted on `/cygdrive/x` below.
> >
> > I finally found that readdir() does not open every file.
> > `ls /cygdrive/x` does not fire any open() call. Perfect.
> >
> > However, `ls -l /cygdrive/x` does, every file is opened, with read access.
> > As `rsync -an /cygdrive/x /tmp/`, which is a dry-run just grabbing files'
> > attributes.
> >
> > I then went through Cygwin code and found that NtCreateFile/NtOpenFile  
> > calls
> > from symlink_info::check() in path.cc may be the culprits.
> > To demonstrate this I added write access to these calls, and found that
> > every file was then opened with write access.
> >
> > Later in this function we have a failback to NtQueryDirectoryFile call.
> > I assume (assume only, I may be wrong) this one does not open the  
> > requested
> > file.
>
> It's nice that you're testing all this, but you should ask *why* Cygwin
> does it in the first place.  The reason is that the information one can
> gather without opening the file on Windows is insufficient to fill in
> all of the stat struct.  The directory info returned by
> NtQueryDirectoryFile just isn't, thus it's only a fallback.

Corinna, thank you very much for your answer.
What info would be missing without opening the file ?

Do you know where the open call could come from, when only using  
NtQueryDirectoryFile in symlink_info::check() ?
(certainly related to the previous question)

Thank you !

Ben