Matthew Dillon wrote:
 > :Yeah, I was thinking about wildcarding as well.
 > :
 > :But is it possible to implement it within cmd_prune.c, or do I have to
 > :modify the ioctl kernel code? If done in cmd_prune.c, I somehow have to
 > :iterate over all deleted files and call the prune command for it.
 > :
 > :I thought, it's easier to introduce a check in the kernel, whether the
 > :file that should be pruned matches a given pattern. Doesn't sound very
 > :hard to do, if it is easy to get the pathname for a given inode.
 > :
 > :Are you thinking about something like the archive flag?
 >
 >     I think it is probably best to implement that level of sophistication
 >     in the utility rather then in the kernel.  The pruning ioctl code
 >     has no concept of files or directories... literally it has no 
concept.
 >     All it understands, really, are object id's (aka inode numbers) and
 >     records.
 >
 >     The hammer utility on the other hand can actually scan the filesystem
 >     hierarchy.
 >
 >     Locating wholely deleted files and directories is not hard to do.
 >     As-of queries can be used to access earlier versions of a directory.

Hm, how would that work, if I want it to behave like the prune command?
I'd need to traverse a lot of filesystem trees, to just determine which
files were deleted.

Imagine:

   compare /mnt with /mnt@1-hour-ago and prune deleted files.

   compare /mnt@1-hour-ago with /mnt@2-hours-ago ...

I wouldn't find files that were deleted in between 1-hour-ago and
2-hours-ago. To make it work, I'd need to compare the filesystem trees
of every possible timestamp.

It's probably easier, and more efficient, to have
separate filesystems.

 >     We might want to add some kernel support to make it more efficient,
 >     for example to make it possible for the hammer utility to have
 >     visibility into all deleted directory entries.  It could use that
 >     visbility to do as-of accesses and through that mechanic would thus
 >     have visibility into all deleted files and directories.

Does this mean, I'd see files like:

   /a@12312323
   /a@12312323/x@...
   /b@43434343

Regards,

   Michael