On Thu, 16 Apr 2015 22:19:46 -0400 Dan Merillat <dan.meril...@gmail.com> wrote:
[Reordered to standard list quote/reply-in-context order.] > On Thu, Apr 16, 2015 at 9:09 PM, Duncan <1i5t5.dun...@cox.net> 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. [...] 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. > 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. That would be much appreciated. =:^) Last time I had to do a restore I had a backup, but it was a bit older than I would have liked. As a result, once I realized ownership/perms metadata wasn't restored, it was simple enough to quick-hack a script to check each restored file against the backup, and where the file existed in both, do a chown and chmod using --reference=$bakfile. That left only the new-since-backup files, which were few enough and obvious enough I could fix them manually. If I'd have not had a backup (if a bit dated), I'd have obviously been even *more* thankful for restore, and probably would have done arbitrary chown/chmod and simply had more manual fixes to do, but I'd have surely been swearing rather more in the process. So patching restore to "just work", restoring all metadata possible (of course it won't always be possible, we /are/ assuming a likely heavily damaged btrfs if we're resorting to restore, so it's not always going to be possible), would be a huge improvement. BTW, symlinks too. At least back then (I think about a year ago, quite some changes since then), restore entirely skipped symlinks. I'm not a coder but I assumed that was because that was entirely metadata, and all it was restoring was data. So I had to manually recreate all my symlinks too. If that could be patched at the same time, I'm sure it'd make a lot of folks happy! =:^) Obviously, if you're resorting to restore, you take what you can get, and I /was/ happy with what I got, if a bit disappointed at the same time, but the more it's possible to get... IMO, getting all that in btrfs restore would surely make for a milestone btrfs-progs release. =:^) -- Duncan - No HTML messages please; they are filtered as spam. "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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
