lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

Hash: SHA1

Enrico Colombini wrote:
> For example, anything hogging CPU or locking down a file long enough
> could possibily cause problems, but they're not too difficult to catch
> if you've at least minimal error handling in place on the Lua side.

Windows has some really disturbing (at least, by Unix standards) file locking
semantics. Basically, on Unix, directory entries and the data are separate
entities; directory entries merely point to the data (the inode). When you
open a file, you get a reference to the inode... which is garbage collected.
This allows you to delete a file while someone else has it open; the inode
remains valid until the last reference goes away, i.e. when the last user
closes the file. Then the OS will quietly remove the inode from the disk and
free up the space.

Windows, however, treats directory entries and data as the same entity. This
means that when a file is open, you can't modify the directory entry. This
includes deleting and renaming them.

So if you have a virus scanner or a RCS system looking at files while you're
trying to modify them, you end up with nasty race conditions where
*occasionally* you'll attempt to do something to a file when the virus scanner
has it open, and it'll fail. For no apparent reason.

This is deeply annoying.

> I forgot: if you're using temporary files, how did you create them?

#tangent: on Unix, the tmpfile() call gives you a FILE* to an open file...
with no directory entry. This means that only user is the FILE*. Close the
FILE*, and the file magically vanishes. Somehow I find this really cool.

- --
┌── ─── ───────────────────
│ "There does not now, nor will there ever, exist a programming language in
│ which it is the least bit hard to write bad programs." --- Flon's Axiom
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla -