This seems to be ancient problem: how to prevent a folder action script or folder-watching launch daemon from starting to act on a file until the file is fully written to disk. I’ve been using the technique that seems to be common, which is to use System Events to test the file size at intervals of n.n seconds, but it slows things down and isn’t really reliable.
Is there a better way to do this?
If you know where the files are coming from there may be other ways, but checking file size is probably the only general method. I’m not sure why you say it’s not reliable.
Thank you for confirming this. And - about “reliable” - I shouldn’t type when tired after a long day traveling. The method is certainly reliable, but only if the script-writer (i.e. me) is competent enough to choose the correct timeout number. In some scripts, I’ve set it to a number that works in 99 percent of cases - and then I come across the one instance where the number is too low, and my script starts acting on the file before it’s complete.
When I script in Windows, there’s an API call that tells instantly whether a file is in use. I’ve read (but of course do not know from experience) that the “lsof” command can do something like this in unix-style systems, but I haven’t seen any useful implementation of it.
In the situation I’m asking about, the files are being generated by a DOS emulator called DOSBox-X - they are print output files redirected from the virtual printer port in the emulator to a disk file. The speed at which they get written depends entirely on the DOS program that generates them - in my project, that’s WordPerfect for DOS in different versions. If WordPerfect is generating pure printer code (PCL or PostScript), the file gets printed almost instantly. if WordPerfect generates graphics data (for example, to create characters or symbols that it doesn’t think exist in the printer hardware), then it may need a few seconds to generate a page.
You can check if a file is in use by trying to open it for read access – if you succeed, nothing else has it open. But that’s not fool-proof either: an app can open-write-close, open-write-close, etc.
Yes, unfortunately, the emulator app that I’m working with does exactly that…