Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: binary MIME-Version: 1.0 X-Mailer: MIME-tools 5.507 (Entity 5.507) RT-Send-CC: X-RT-Original-Encoding: iso-8859-1 Content-Length: 1211 The profile library is designed to automatically pick up changes to the profile each time a profile_get_* call is made. This feature is of dubious usefulness, because our code base is inconsistent about how long it caches profile results for, but I've been reluctant to simplify it out. To do this, it calls stat() and compares the mtime to the mtime from the previous stat() result. It does compare fractional timestamps, so you would think the double-read would happen all the time (since stat() on /dev/fd/NN appears to just give the current time). However, there is also a guard against issuing too many stat() system calls; at prof_file.c:316 we compare the current time to the last time we read the filed or called stat(), and only issue a new stat() call if the second has ticked over. So I think in your scenario a failure only happens if the second ticks over between the initial profile open and the profile read to get the stash filename. I think we could fix this scenario from our side by disabling the stat-and-reread behavior for things that aren't regular files as determined by S_ISREG(). From your side, you could of course work around the issue by using a regular file.