Cezary Wagner <cezary.wag...@gmail.com> added the comment:

I think we can assume that NTFS is priority since that is the most used option.

I can not discuss what with FAT32 or FAT since I am not the best in this domain 
(in NTFS I am not the best too now). Whatever I think that system must do 
allocation for open files to avoid conflicts so it can be tracked but how?

Possible solutions is some extra function, argument for Windows - which makes 
cache dirty between calls.

It is very dirty proposal - I need to think if it is good. Even used names is 
ugly I need think more about it. My imagination tells me that it can be good 
direction.

dir_entry.stat(nt_force_cache_refresh=True) - it can be good for specific 
entries.
os.scandir(nt_force_cache_refresh=True) - it is sometimes not need for all 
entries

I am thinking:
dir_entry.stat(nt_force_cache_refresh=True) should be faster than 
os.stat(dir_entry.path) instead dir_entry.stat() which not works fo open files.
os.scandir(nt_force_cache_refresh=True) should be faster than 
dir_entry.stat(nt_force_cache_refresh=True) and dir_entry.stat() will work for 
open files. It is simpler to understand that Windows is different if such extra 
attribute must be added at all.

nt_force_cache_refresh can add to dir_entry some information that .stat() 
should not use cache.

Then best will be to not use nt_force_cache_refresh for open files - maybe you 
will find the way to detect open files in external application. I think Windows 
API allow to check if file is open - as far as remember sysinternals tools can 
do this so there some API for it I think.

See this tool: https://docs.microsoft.com/en-us/sysinternals/downloads/handle - 
maybe there is source code for it or you can learn for it.

Maybe you can check if file is open with use this API before dir_entry.stat()

I do want to force any solution but just share some rough ideas.

----------

_______________________________________
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

Reply via email to