On Thu, 25 Apr 2002, Horst wrote:
>
>On kernel 2.2 and 2.4, both ext2:
>
>What happens if a cronjob(root) attempts
> mv /var/spool/mail/bucket someOtherFilename
>while sendmail is appending another message to user bucket's inbox at
>the same time.
The message will get appended to someOtherFilename.
One of the important things to remember about Linux filenames (and UNIX
filenames in general) is that they only get used when the file is first
opened. Once a program has a file open, the kernel remembers the disk
locations of the file's data blocks, and can do most I/O without further
reference to the file's name.
This has some important effects:
1. If you rename a file while some other process is using it, the other
process will continue to access the same file (with its new name).
2. If you change a file's access permissions, the other process will still
be able to access the file under its old permissions.
3. You can even delete a file while some other process is using it. The
process that's using it will be able to continue using it as if it had
never been deleted. The kernel will remove the file's name, but won't free
up its data blocks until the last user of the file is through with it.
(Your programs can use this behavior to create "stealth" files that exist
on the disk but don't have any name. There is a danger, though--if the
system crashes while a "stealth" file is in use, the disk will be left in
an inconsistant state, which fsck will have to fix at the next boot (by
inventing a name for the file and putting it in the partition's lost+found
directory).)
> - Is there a chance to corrupt the file, or the file system?
Not from just a rename. But see the above warning about deleting an in-use
file and then crashing the system.
> - a quick search points to 'chattr +S fileName' to achieve synchronous
>behavior -- a more extented search extended the confusion on my end...
> How does the kernel respond to a second write/move request while the
>file is written to? a) reject the request, or b) wait and do it later?
As mentioned above, a move (rename) is safe.
When two processes try to write to the same file at the same time, you can
get trouble. Both writes will succeed, with the one that gets there
earlier writing first, and then the one that gets there later. This can
lead to information from two programs getting interleaved in the file. For
some purposes, such as a log file, that may be exactly what you want, but
for other purposes, such as updating a database, it can corrupt the data.
Fortunately UNIX provides tools to help a process protect against multiple
simultaneous writers. There is a system call that places an "advisory
lock" on a file (or a portion of a file). Any process that wants to access
a file can check for the presence of the lock, and if it's already in
place, wait until the other process releases it.
Note, though, that the lock mechanism is voluntary...nothing protects
a locked file from a process that never bothers to check the lock. For
that kind of protection, the easiest thing to do is to use file access
permissions to restrict the file so that unauthorized processes can't open
it (i.e., run the authorized processes under their own user or group ID,
and set the file permissions so that only that user or group can access
the file).
IMPORTANT EXCEPTION:
If you're accessing files on a remote server over NFS, all bets are off,
and everything I said above is wrong. NFS doesn't hold the file open on
the server end...in effect, every single I/O request by the client causes
the server to reopen the file, do the I/O, and close it. This means that
any process accessing a file over NFS will immediately see the effects of a
change of name or permissions. Also, some versions of NFS, such as
Linux's, don't support locks.
- Neil Parker, [EMAIL PROTECTED]
