gnu-arch-users
[Top][All Lists]
Advanced

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

Re: [Gnu-arch-users] Re: extended attributes


From: Jan Hudec
Subject: Re: [Gnu-arch-users] Re: extended attributes
Date: Tue, 6 Jan 2004 11:14:43 +0100
User-agent: Mutt/1.5.4i

On Tue, Jan 06, 2004 at 01:02:10 -0500, Aaron Bentley wrote:
> Tom Lord wrote:
> 
> >   > From: Aaron Bentley <address@hidden>
> >
> >   > Perhaps a fully transactional filesystem was never what was needed. 
> >   > Maybe all that's needed is a variant of rename(2) that only changes 
> >   the
> >   > number of links, atime and mtime.
> >
> >Huh?  Can you explain in more detail what you are thinking of because
> >I don't get it from that description.   
> > 
> >
> For atomic file updates, rename(2) does too much.  It modifies or 
> creates a directory entry to have default ownership, permissions and 
> time values.

Do I need to remind you, that *directory entry* does NOT have any
ownership, permission and time values? A *directory entry* has exactly
a name and a number of inode it point to. At least for POSIX compliant
filesystems.

> >mtime?   really?  What?!?
> 
> I mean "file modification time" from struct stat's st_mtime.
> 
> A variant of rename could be called move_contents().  It would simply do 
> less.  Not change ownership, permissions or file creation time.  But it 
> could change #of links, would change inode, modification time and access 
> time.  An update done with open() and write()  would not change inode or 
> links, but I think this is as close as you can get to atomic updates 
> without adding locks or another layer of indirection.

You are not talking about unix, right?

rename() touches exactly one filed in the inode -- the ctime (inode
change time). ALL other fields remain untouched. This includes
especially the owner, mode, nlinks, atime and mtime.In addition, rename
can result in unlink() equivalent on exactly one other inode (the
original target of new name) and change of mtime (and possibly link
count if dir is renamed or removed) of one or two directories (parents
of old and new name).

(In fact, Linux VFS does not enforce even the changes above -- it's the
filesystem's responsibility to update ctime on moved file and mtime on
parents).

-------------------------------------------------------------------------------
                                                 Jan 'Bulb' Hudec 
<address@hidden>




reply via email to

[Prev in Thread] Current Thread [Next in Thread]