From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <4B71D35A.5070304@magma.com.ni>
Date: Tue,  9 Feb 2010 22:27:54 +0100
From: Georg Lehner <jorge-plan9@magma.com.ni>
User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090706)
MIME-Version: 1.0
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
References: <4B71017C.8080505@magma.com.ni>
	<8909eef9c8d57660ccd6e1cfa4aa2091@ladd.quanstro.net>
In-Reply-To: <8909eef9c8d57660ccd6e1cfa4aa2091@ladd.quanstro.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [9fans] walk and find again
Topicbox-Message-UUID: d1c19c92-ead5-11e9-9d60-3106f5b1d025

erik quanstrom wrote:
>> One usage scenario of walkfs is to implement find, du, walk, rdup and
>> the like. Another usage [scenario] of walkfs, with the -s option, is to add file
>> indexing to a
>> fileserver.
>>
>
> this seems more complicated than a straightforward
> non-fileserver based implementation.  why do you
> need a fileserver for this?
>
> - erik
>
>

- Every three months there need to be a discussion about 'find', right ;)
- walkfs can cache/reuse results from previous runs
- arbitrary filesystem indexing and lookup schemes can be implemented
  without changing the frontend-interface.  Consider mime-type or
keyword lookup
- no more hassle with space or other special characters in filenames
- inaccessible parts of the filesystem are just masked out, instead of
returning
  errors.
- ...

frontend tools are simple straightforward rc-scripts, consider:

find:
  get a new walker thread
  write filter to ctl file
  write path to root file
  while !eof {
    path = read data
    do with path whatever has been specified
  }

du -s:
  get a new walker thread
  write path to root file
  write "mode=stat" to the ctl file
  read data (and block until walk is done)
  print count and size


Best Regards,

    Jorge-Le�n