Re^2: Testing unexpected I/O failures

G'day GrandFather,

Thanks for the suggestion. I had a look at the documentation for that module. From what I read, its main purpose is to allow testing of code/logic without touching the filesystem, which isn't really my problem.

Whether a real or a mocked file, there would only be a few CPU cycles between the file checks (-e, -r, etc.) and the open call: that only provides a very tiny window for something to change such that, for instance, -r is successful but open subsequently finds that the file does not have read permission.

Anyway, thanks for replying and offering a suggestion.

— Ken

Comment on Re^2: Testing unexpected I/O failures Select or Download Code

Replies are listed 'Best First'.
Re^3: Testing unexpected I/O failures by bliako (Abbot) on Nov 24, 2020 at 11:22 UTC
So, do you want to be able to test what happens (or detect it) when within these few CPU cycles some other process modifies the file while your Perl process does IO? Or do you want to ignore this risk? As a side remark, on top of race conditions you also have buffered IO routines. Do these keep IOing even if the file is gone / file permissions changed until the buffer is exhausted? If that's the case you will always get a delayed picture.	[reply]
Re^4: Testing unexpected I/O failures by kcott (Archbishop) on Nov 24, 2020 at 20:29 UTC
G'day bliako, I'm really just interested in detecting a change rather than investigating who or what effected the change. In the unlikely event that this issue occurs frequently, that focus may change. My reponse to ++Fletch's reply has a bit more detail about what's going on. At this stage, his suggestion is the one I'm most likely to implement. — Ken	[reply]