Re: [PATCH] Re: ext2fs problem with rename() system call

Jamie Lokier (lkd@tantalophile.demon.co.uk)
Sat, 9 Jan 1999 08:07:41 +0000


On Sat, Jan 09, 1999 at 12:41:41AM +0000, Stephen C. Tweedie wrote:
> On Wed, 6 Jan 1999 11:34:48 +0000, Jamie Lokier said:
>
> > There is a problem with the rename() system call in 2.1.131 on ext2fs.
> > 1. The problem is that if source and destination are the same file, it
> > returns zero ("success") but does not remove the source file. It
> > should remove the source file.
>
> Really?
>
> [POSIX.1 and singleunix specs]

Not having a POSIX.1 spec, I assumed the more intuitive semantics would
be right... The POSIX-specified behaviour still seems weird to me, but
we must stick to it.

> Looks fine to me. Why do you think the behaviour should be different?

Are you telling me that

rename("a", "b") = 0
lstat("a") = 0

make sense? ;-)

> > 3. `new_dir' is always marked dirty, version is incremented etc.
> > These are not necessary when renaming over an existing file in
> > a different directory. This is probably quite rare though.
>
> We have to update the mtime in the new directory, which requires it to
> be marked dirty.

I don't think you have to update the mtime if the directory doesn't
change (i.e., the (name,inode) list stays the same. But someone had
better check the standards.

> > 7. `old_dir->i_ctime' need not be updated if an inode is renamed
> > within a directory, and the destination did not exist already.
> > However, `old_dir->i_mtime' should always be updated. This is not
> > easy to fix, because the call to `ext2_add_entry' updates
> > `old_dir->i_ctime' itself.
>
> No, ctime always needs to be updated any time anything in the inode is
> modified. (Remember, it means change-time, not create-time.)

ctime is not updated when a file is modified, only when its attributes
change.

Similarly in case 7., the directory is modified by the rename, but its
attributes (not counting mtime) do not change. In particular, the link
count stays the same. So there's no need to updated ctime, unless the
standards have something to say on this.

> Bad, and...
> ...unpleasant. Both fixed in the patchlet below.

Patch looks fine to me.

-- Jamie

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/