in reply to Best practices for modifying a file in place: q's about opening files, file locking, and using the rename function

I'm concerned that the rename function implicitly closes the file being renamed and breaks the lock on it before doing something as drastic as renaming it.
rename is an operation on the directory, not on the file. This is why you need write access to a directory to rename a file - no access is required to the file itself (this applies to UNIX).
  • Comment on Re: Best practices for modifying a file in place: q's about opening files, file locking, and using the rename function

Replies are listed 'Best First'.
Re^2: Best practices for modifying a file in place: q's about opening files, file locking, and using the rename function
by 0xbeef (Hermit) on Nov 03, 2006 at 12:01 UTC
    As a side-note, it is rename() that does not work across file systems. The "mv" command itself actually acts as a wrapper when the source / destination are on different file systems.

    Depending on the UNIX implementation, there are some considerations that may arise when moving a file across filesystems:

    1) The source file is copied to the target filesystem and then deleted. It is roughly equivalent to "rm -f DEST && cp -PRp SRC DEST && rm -rf SRC".
    2) mv must explicitly copy modification/access time, ownership and mode.
    3) on some Unix systems, setuid/setgid permissions are not preserved.
    4) ACLs may or may not be replicated.

    Hence the Cookbook warning on rename() across file systems. The "mv" command actually does work across filesystems on modern UNIX systems, since it is a requirement of IEEE Std 1003.1-2001.

    Regards,
    Niel

[reply]

In Section Seekers of Perl Wisdom