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/