It seems that FileSystemInfo.Refresh requires specific rights on the file even though I can't find anything about it in the documentation. I suspect it requires write access to properly work.
Is there a way to check whether a call to that method failed? It doesn't throw any exception even though it did nothing while it should have. I could check the rights available for the file (and do something different for read-only files) but I would ideally want to handle the general case.
Some context:
I wrote a piece of software that tracks log files written by another software. I use an instance of FileSystemWatcher to listen to the file system changes. I noticed that even though the log file is modified by the third party software, the Changed event is not triggered and the "Date modified" showed in the file explorer was not updated either.
I then discovered that opening the log file (in notepad for instance) forced the timestamp update (and subsequently triggered the Changed event of my FileSystemWatcher).
I concluded that the third party was updating logs with some sort of stream that was not changing the last modified timestamp (probably never closing the stream? I'm not sure how this is achieved). Opening the log file manually would basically refresh the file system information about the file, which would let my code know an update happened.
The solution I found was to schedule a periodic call to FileSystemInfo.Refresh on the files I was monitoring (like every 2 seconds). If the file wasn't changed, nothing would happen (as expected) but if the third party appended lines then my FileSystemWatcher would raise the Changed event.
It worked very well (doesn't look pretty though) except that some users reported that it doesn't do the trick (if they opened the log file in notepad, the log watching process would catch up).