Wiggins D Anconia wrote:
<snip>
Depending on what is writing the files, aka another controllable program? I have had good luck with writing the file to a temporary location, usually with a dot on the front, then executing a move from that temp location to the real name. A move is usually a single action (at least that's my understanding) and for most filesystems is merely a single inode update. Then just have the directory watcher skip dot files... Though the lock would probably be better...
Hi Wiggins.
Yes, that will often work, depending on the filing system. But a 'move'
will usually do 'copy' followed by 'delete'.
What filesystems act in that matter? I believe you that there are ones that do it that way, none of the Unix variants that I have experienced do (or seem to). Unless we are talking about 'mv' as opposed to 'rename' which I should have been more explicit about. A rename merely moves the starting inode, assuming the file is staying on the same partition, which in this case if the temporary file is written into the same directory then it is...
Occasionally you can move
a file while it is being written to, as the application doing the writing doesn't care where it appears in the directory structure. But that's unusual. It's more common that the 'copy' will be allowed to grab an image of the data flushed so far and the subsequent 'delete' will be executed once the writing app has closed the original file.
Without extensive knowledge of the platform and filing system I don't think it's safe to assume anything!
Right which is why the locking is better. However, in many cases one will be familar enough with the system where the code is deployed, so this method is just shorter (to code).
http://danconia.org
-- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] <http://learn.perl.org/> <http://learn.perl.org/first-response>
