>> Perhaps all that is unnecessary: rather than doing the walk, why not >> make use of btrfs subvolume find-new (or rather, the syscalls it >> uses)? > > While developing snapper I faced similar problems and looked at > find-new but unfortunately it is not sufficient. E.g. when a file > is deleted find-new does not report anything, see the reply to my > mail here one year ago [1]. Also for newly created empty files > find-new reports nothing, the same with metadata changes. > > If I'm wrong or find-new gets extended I happy to implement it in > snapper. For a system-wide undo'ish sort of thing that I think autosnapper is going for, it should work quite nicely, but you're right that it doesn't help a whole lot with a backup system. It can't tell you which files were touched or deleted, but it will still tell you that _something_ in the subvolume was touched, modified or deleted (at least, as of the last commit), which is all you need if you're only ever comparing it to its source. -- Carey -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
