Eryk Sun <eryk...@gmail.com> added the comment:
> What it also means is that the "file still in use by another app" > scenario will probably have to manually use os.stat(). We can't > detect it, and it's the same race condition as calling os.stat() > shortly before the update flushes anyway. FAT filesystems require an fsync (FlushFileBuffers) or close on the in-use file in order to update the last-write time in both the directory entry and the file control block (i.e. FCB, which is shared by all opens). It seems the developers take the meaning of "last write" literally in terms of the last time that cached data was flushed to disk. Because the last-write time in the FCB is updated separately from the file size in the FCB, even an [l]stat on an in-use FAT file may see st_size change while st_mtime remains constant, as I showed in the previous post. No matter whether we query the directory or the FCB, the reported last-write time of a FAT file might be wrong from the standpoint of reasonable expectations. An fsync call is also useful with NTFS, but it only updates the directory entry of the opened link. It doesn't update other links to the file. On the other hand, with an NTFS file, calling os.[l]stat or os.fstat is sufficient to get updated stat information, regardless of the link that's accessed. > What this probably means is if we can detect a link from the FFD struct > (which I think we can?) then we can cache the attributes we trust and > send .stat() through the real call. It would nice if we could detect the link count without an additional system call. But it's not in the duplicated information in the directory entry and wouldn't be reliable if it were. The link count is available via GetFileInformationByHandleEx: FileStandardInfo, but if you're calling CreateFileW to open the file, you may as well get the full stat result while you're at it. We're faced with the choice between either always calling the real lstat, or just documenting that files with hard links will have stale information if the file was updated using another link. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue41106> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
