Gareth Clay posted on Thu, 17 Jul 2014 23:09:08 +0000 as excerpted: > I'm not fully sure about the btrfs restore -x behaviour either. > Ownership of the restored files is still incorrect, but maybe it > affects r/w/x permissions, which look fairly sensible for the small set > of files I've looked at so far... Thanks and good to read that you eventually able to successfully restore most of the files too. A wakeup call indeed! I've always stressed backups with btrfs and did have them, so wouldn't have been too bad off if I had to revert to them. I'd simply let them get inconveniently outdated, and between that and the chance it gave me to actually get real experience with btrfs restore, I decided to try it first. But your reply reminded me... Something think I forgot to mention is that btrfs restore didn't restore symlinks, at all, not as symlinks and not as copies of the files they pointed at. It was as if the symlinks simply didn't exist on the source filesystem I was restoring from, so I'm guessing the implementation simply overlooked symlinks as something it needed to deal with. Meanwhile, on ownership/permissions I think btrfs restore must simply find the data and write it out as the user (presumably root) it is run as, using the existing umask, just as a normal user file write would do by default. So if your root and user umasks are identical (presumably 0022), you probably won't notice the permissions difference. My root umask is 0022 while my user umask is 0027, so I noticed. -- 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
