On Sep 12 13:41, Corinna Vinschen wrote: > On Sep 12 10:49, Yoni Londner wrote: > > Hi, > > > > The caching-speed up is trivial: > > We store the the FileFullDirectoryInformation fields, and if any of > > them change - we re-read the file. > > > > Its not (in practical life) possible to change a file without > > causing a modification on > > FileIndex/CreationTime/LastWriteTime/ChangeTime/EndOfFile/AllocationSize/FileAttributes/FileName/EaSize! > > > > From the MSDN we see the info we can get on a > > FileFullDirectoryInformation request: > > We're already using FileBothDirectoryInformation and > FileBothIdDirectoryInformation in readdir anyway. > > However, isn't that kind of a chicken/egg situation? If you want to > reuse the content of the FILE_BOTH{_ID}_DIRECTORY_INFORMATION structure > from a previous call to readdir, you would have to call the > corresponding NtQueryInformationFile call(s) to fetch the information > from the file for comparision purposes. When you fetched it anyway, > there's no reason anymore to compare them, since you can use what > you just fetched. Where's the advantage?
The patch I still have in the loop uses the FILE_NETWORK_OPEN_INFORMATION structure throughout, starting in symlink_info::check. The content is then stored in the path_conv structure and reused in fhandler_disk_file::fstat_by_handle. If the content of that structure would be used as fingerprint, then we could perform readdir/stat caching without requiring fstatat. Something similar could be used to perform ACL caching, so that a typical `ls -l foo' would not request the ACL two or three times, but only once... Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat