On Mon, 2008-12-01 at 09:54 +0000, Thierry Carrez wrote:
> My concern with this solution is the separation of the permission
> metadata store from the files/directories object they cover. For
> example, in case of file renaming (or swapping), which is a common
> case
> for configuration files, you'd more than probably lose
> permission/ownership history.
The most immediate way to address that concern is to key the separate
metadata by fileid, rather than by path. Alternatively we can call into
plugin code on renames so that it can update the separate store.
At this point I'd really like to avoid depending on changes down at the
deep inventory level: depending on such a facility would make this a
large change rather than a small change.
On Mon, 2008-12-01 at 09:54 +0000, Thierry Carrez wrote:
> My concern with this solution is the separation of the permission ownership history.
> metadata store from the files/directories object they cover. For
> example, in case of file renaming (or swapping), which is a common
> case
> for configuration files, you'd more than probably lose
> permission/
The most immediate way to address that concern is to key the separate
metadata by fileid, rather than by path. Alternatively we can call into
plugin code on renames so that it can update the separate store.
At this point I'd really like to avoid depending on changes down at the
deep inventory level: depending on such a facility would make this a
large change rather than a small change.
-Rob
-- www.robertcolli ns.net/ keys.txt>.
GPG key available at: <http://