On 4 Feb 2015 at 7:37, Rob Stewart wrote:
I had thought you were recommending an ACL lookup for path viability.
I was thinking that would be useful while we were at it, but I recognize that's easily overreaching.
Also, Windows can only open 30k file handles per second even across eight CPU cores. It's an enormous performance bottleneck. And you can't check ACLs without opening the file.
No I meant that temp_directory_path() basically needs to iterate those options I listed. If the given environment variable does not expand to a valid path (note no FS operations needed here), we move to the next option. We don't check for feasibility.
How would you judge that the expansion is a valid path? A regex or something else?
Perhaps even simpler. Does the environment variable exist, and does it have contents.
For the function which creates temp files for you, it may be useful to know what I'll be doing there. AFIO won't provide any facility for knowing about paths of temp files until after you have created one. Instead you get a dispatcher implementation which creates either anonymous temp files or named temp files at some one of many unknown locations until after file creation (the unknown locations which can be chosen from is user suppliable, so I guess if you supply a single option you get some control), plus you can request "fast moveability" to another given path i.e. that the temp file location be chosen to be on the same volume as the path supplied where possible, thus ensuring that mv works quickly. I just added the support code for that via the new statfs() call in AFIO v1.3 which might ship this week or next week.
Sometimes the user needs full control over the location of temp files so they can be manually deleted when left by applications. For those that are unlinked after opening (there's a flag for that on Windows I don't recall), that's not an issue, of course. However, the code getting the temp path knows which will be done, so must be given control.
Ah, you strike exactly at a major new feature hopefully in AFIO v1.4. Getting temp files to behave on a Samba or NFS share which is being accessed concurrently by Windows and POSIX is a nest of vipers. AFIO will hopefully abstract away all that complexity. You get temp files which "just work" and you can forget about clean up. The same code obviously enough also works on a local drive. And, interestingly, to make all of the above work we need a non-braindead, functioning and portable byte range file advisory locks abstraction layer, so you'll have one of those too (they are used to portably detect when a temp file is no longer being used, and therefore can be cleaned up. The special delete on close flag on Windows you mentioned does not work correctly on a SMB share, including on Microsoft's own implementation, so we can't use that. Windows also does not let you delete files with open handles [1]). [1]: Actually it does if carefully asked to, AFIO uses that feature for its lock file implementation. Unfortunately the name of the deleted file continues to exist though hidden from view and any attempt to create a file of the same name will fail with a very unspecific win32 error code of ACCESS_DENIED. The workaround to match POSIX unlink semantics is to rename the file to a random hex name, _then_ to delete it. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/