That's not a bad idea. In my case it was all owned by the same user (media storage) so the only thing of interest was the timestamps. I can whip up a patch to do that as well. On Thu, Apr 16, 2015 at 9:09 PM, Duncan <1i5t5.duncan@xxxxxxx> wrote: > Dan Merillat posted on Thu, 16 Apr 2015 19:33:46 -0400 as excerpted: > >> The inode is already found, use the data and make restore friendlier. > > Unless things have changed recently, restore doesn't even restore user/ > group ownership, let alone permissions. IOW, atime/mtime are the least > of the problem (particularly if people are running noatime as is > recommended, unless you really need it for some reason). > > It simply creates the files it restores as the owner/group it is run as > (normally root), using standard umask rules, I believe. > > So if you're going to have it start restoring metadata at all, might as > well have it do ownership/perms too, if it can. Otherwise atime/mtime > are hardly worth bothering with. > > -- > Duncan - List replies preferred. No HTML msgs. > "Every nonfree program has a lord, a master -- > and if you use the program, he is your master." Richard Stallman > > -- > 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 -- 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
