On Thu 08-11-07 09:37:59, Theodore Tso wrote:
> Ah, OK, so the two things that I didn't get from your patch
> description are:
>
> 1) the rtime flag and rtime field are only set on directories
> 2) the intended use is not trackerd and its ilk, but rsync and updatedb,
>so it is desirable that s
Ah, OK, so the two things that I didn't get from your patch
description are:
1) the rtime flag and rtime field are only set on directories
2) the intended use is not trackerd and its ilk, but rsync and updatedb,
so it is desirable that scan/queries be persistent across reboots
But then the maj
On Wed 07-11-07 19:20:38, Theodore Tso wrote:
> On Wed, Nov 07, 2007 at 03:36:05PM +0100, Jan Kara wrote:
> > > What if more than one application wants to use this facility?
> >
> > That should be fine - let's see: Each application keeps somewhere a time
> > when
> > it started a scan of a subtr
On Wed, Nov 07, 2007 at 03:36:05PM +0100, Jan Kara wrote:
> > What if more than one application wants to use this facility?
>
> That should be fine - let's see: Each application keeps somewhere a time
> when
> it started a scan of a subtree (or it can actually remember a time when it
> set the f
On Tue 06-11-07 18:01:00, Al Viro wrote:
> On Tue, Nov 06, 2007 at 06:19:45PM +0100, Jan Kara wrote:
> > Implement recursive mtime (rtime) feature for ext3. The feature works as
> > follows: In each directory we keep a flag EXT3_RTIME_FL (modifiable by a
> > user)
> > whether rtime should be updat
On Tue 06-11-07 14:40:12, Theodore Tso wrote:
> On Tue, Nov 06, 2007 at 06:19:45PM +0100, Jan Kara wrote:
> > Intended use case is that application which wants to watch any
> > modification in a subtree scans the subtree and sets flags for all
> > inodes there. Next time, it just needs to recurse i
On Tue 06-11-07 10:04:47, H. Peter Anvin wrote:
> Arjan van de Ven wrote:
> >On Tue, 6 Nov 2007 18:19:45 +0100
> >Jan Kara <[EMAIL PROTECTED]> wrote:
> >
> >>Implement recursive mtime (rtime) feature for ext3. The feature works
> >>as follows: In each directory we keep a flag EXT3_RTIME_FL
> >>(mod
On Tue, Nov 06, 2007 at 06:19:45PM +0100, Jan Kara wrote:
> Intended use case is that application which wants to watch any
> modification in a subtree scans the subtree and sets flags for all
> inodes there. Next time, it just needs to recurse in directories
> having rtime newer than the start of t
Arjan van de Ven wrote:
On Tue, 6 Nov 2007 18:19:45 +0100
Jan Kara <[EMAIL PROTECTED]> wrote:
Implement recursive mtime (rtime) feature for ext3. The feature works
as follows: In each directory we keep a flag EXT3_RTIME_FL
(modifiable by a user) whether rtime should be updated. In case a
direct
On Tue, Nov 06, 2007 at 06:19:45PM +0100, Jan Kara wrote:
> Implement recursive mtime (rtime) feature for ext3. The feature works as
> follows: In each directory we keep a flag EXT3_RTIME_FL (modifiable by a user)
> whether rtime should be updated. In case a directory or a file in it is
> modified
On Tue, 6 Nov 2007 18:19:45 +0100
Jan Kara <[EMAIL PROTECTED]> wrote:
> Implement recursive mtime (rtime) feature for ext3. The feature works
> as follows: In each directory we keep a flag EXT3_RTIME_FL
> (modifiable by a user) whether rtime should be updated. In case a
> directory or a file in it
Implement recursive mtime (rtime) feature for ext3. The feature works as
follows: In each directory we keep a flag EXT3_RTIME_FL (modifiable by a user)
whether rtime should be updated. In case a directory or a file in it is
modified and when the flag is set, directory's rtime is updated, the flag i
12 matches
Mail list logo
