Suggestion for rm(1)
rm(1) says, quite correctly: Note that if you use rm to remove a file, it is usually possible to recover the contents of that file. This is aimed at those who wish to make sure their data is deleted. However, it may falsely reassure those who wish to recover deleted data. I suggest adding some text, along the lines of: Note that if you use rm to remove a file, it is usually possible to recover the contents of that file, though it is generally difficult and/or time-consuming to do so. This also gives a more accurate idea of how much effort it is to recover data once rm'ed: often rm is enough. -- http://rrt.sc3d.org
Re: Suggestion for rm(1)
On 10/03/10 13:46, Reuben Thomas wrote: rm(1) says, quite correctly: Note that if you use rm to remove a file, it is usually possible to recover the contents of that file. How about just doing: s/is usually/might be/ cheers, Pádraig.
RE: Suggestion for rm(1)
Pádraig Brady wrote: On 10/03/10 13:46, Reuben Thomas wrote: rm(1) says, quite correctly: Note that if you use rm to remove a file, it is usually possible to recover the contents of that file. How about just doing: s/is usually/might be/ what about adding a hint to `shred`? Have a nice day, Berny
Re: Suggestion for rm(1)
On Wed, 10 Mar 2010 14:08:33 + Reuben Thomas r...@sc3d.org wrote: 2010/3/10 Pádraig Brady p...@draigbrady.com: How about just doing: s/is usually/might be/ That seems to me to go a little too far towards reassuring the user that the data has probably gone. We want to say two not obviously conflicting things: 1. After rm the data is most probably still there. 2. After rm it's probably quite a bit of trouble to recover it. How about ... it might be possible, but not easy, to recover ...? Cheers, ..C.. signature.asc Description: PGP signature
Re: Suggestion for rm(1)
On 10 March 2010 14:17, C de-Avillez hgg...@ubuntu.com wrote: On Wed, 10 Mar 2010 14:08:33 + Reuben Thomas r...@sc3d.org wrote: 2010/3/10 Pádraig Brady p...@draigbrady.com: How about just doing: s/is usually/might be/ That seems to me to go a little too far towards reassuring the user that the data has probably gone. We want to say two not obviously conflicting things: 1. After rm the data is most probably still there. 2. After rm it's probably quite a bit of trouble to recover it. How about ... it might be possible, but not easy, to recover ...? I am also trying to convey the fact that an expert can offer recover deleted data quickly *and* easily. -- http://rrt.sc3d.org
Re: Suggestion for rm(1)
Reuben Thomas wrote: On 10 March 2010 14:17, C de-Avillezhgg...@ubuntu.com wrote: How about ... it might be possible, but not easy, to recover ...? I am also trying to convey the fact that an expert can offer recover deleted data quickly *and* easily. Can him? It largely depends on filesystem and content characteristics, but I don't think that's easy for experts. It's much easier (and reliable) for the user to get an expert to do it, though. :)
Re: Suggestion for rm(1)
On 10 March 2010 23:18, Keisial keis...@gmail.com wrote: Reuben Thomas wrote: On 10 March 2010 14:17, C de-Avillezhgg...@ubuntu.com wrote: How about ... it might be possible, but not easy, to recover ...? I am also trying to convey the fact that an expert can offer recover deleted data quickly *and* easily. Can him? It largely depends on filesystem and content characteristics, but I don't think that's easy for experts. It's much easier (and reliable) for the user to get an expert to do it, though. :) I said that it is often easy for experts, not always. I believe this is true, yes. -- http://rrt.sc3d.org
Re: Suggestion for rm(1)
Reuben Thomas wrote: On 10 March 2010 23:18, Keisialkeis...@gmail.com wrote: Reuben Thomas wrote: I am also trying to convey the fact that an expert can offer recover deleted data quickly *and* easily. Can him? It largely depends on filesystem and content characteristics, but I don't think that's easy for experts. It's much easier (and reliable) for the user to get an expert to do it, though. :) I said that it is often easy for experts, not always. I believe this is true, yes. There's a difference between offer and often :) In my opinion, once you lose the block pointers, the problem becomes quite hard. If it happens that all the blocks are contiguous, an expert can view the file in the raw data. But otherwise i don't consider that any easy. If it's a compressed file you could check all free blocks to see which ones match appended to the file begin. That can be easy for the expert, but the algorithm itself is O(n!).
Re: Suggestion for rm(1)
On 10 March 2010 23:52, Keisial keis...@gmail.com wrote: Reuben Thomas wrote: On 10 March 2010 23:18, Keisialkeis...@gmail.com wrote: Reuben Thomas wrote: I am also trying to convey the fact that an expert can offer recover deleted data quickly *and* easily. Can him? It largely depends on filesystem and content characteristics, but I don't think that's easy for experts. It's much easier (and reliable) for the user to get an expert to do it, though. :) I said that it is often easy for experts, not always. I believe this is true, yes. There's a difference between offer and often :) Oops, sorry, I hadn't spotted my typo. This discussion is getting pointlessly technical. rm(1) already makes it look as if data recovery is easy. I'm already trying to say that it can in fact be quite tricky, without implying that shred is not necessary if you really want to delete your data securely. Here's another attempt: Note that if you use rm to remove a file, it is usually possible to recover the contents of that file, given sufficient expertise and/or time. -- http://rrt.sc3d.org
Re: Suggestion for rm(1)
Keisial wrote: Reuben Thomas wrote: I am also trying to convey the fact that an expert can offer recover deleted data quickly *and* easily. Can him? It largely depends on filesystem and content characteristics, but I don't think that's easy for experts. At the time that original text in the rm man page was written I think we were all using older filesystems to which that statement applied. Filesystems such as the commercial ones or the new free ext2 were the common use then and there certainly were tools to recover files. But as time has passed I think the logic of it has flipped. Now almost everyone uses a journaling filesystem. Now probably the most common filesystem used by people is the ext3 with ext4 becoming more popular in the future. (Not to slight xfs and others. :-) In ext3 as I understand it (http://batleth.sapienti-sat.org/projects/FAQs/ext3-faq.html) this is much more difficult because the block pointers are zero'd out. As I understand it you can only wade through the see of possibly gigs of raw data and maybe snag blocks that haven't been reused. You would have to manually decide that certain data lined up with other certain data to form a particular file and the order and if you got all of it or not. That would be very tedious for most computer users today. And if the filesystem is active then probably impossible as the blocks are reused. But of course since it might be possible to recover something if you are willing to go the to the effort[1] then those really trying to prevent the data from being accessed need to do more than just remove it. Bob [1] http://en.wikipedia.org/wiki/Project_Azorian
Re: Suggestion for rm(1)
On 03/10/2010 04:59 PM, Reuben Thomas wrote: Here's another attempt: Note that if you use rm to remove a file, it is usually possible to recover the contents of that file, given sufficient expertise and/or time. Given newer file systems, I'd rather see something like: Note that if you use rm to remove a file, it might be possible to recover the contents of that file, given sufficient expertise and/or time. If you want more assurance that the contents are truly unrecoverable, consider using shred. That is, we want to point out that shred is better than rm at killing data, while at the same time reducing the newbie impression that recovery is easy, since it usually is not. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
--enable-xattr gives #define USE_XATTR yes instead of 1
Which on my new system causes the check in src/cp.c #if !USE_XATTR to be true and makes cp bail out when trying to preserve attributes. Changing it to 1 in lib/config.h fixes it. % grep AC_DEFINE.\*USE m4/*.m4 m4/acl.m4: AC_DEFINE_UNQUOTED([USE_ACL], [$use_acl], m4/threadlib.m4: AC_DEFINE([PTHREAD_IN_USE_DETECTION_HARD], [1], m4/threadlib.m4: AC_DEFINE([USE_POSIX_THREADS], [1], m4/threadlib.m4: AC_DEFINE([USE_POSIX_THREADS_WEAK], [1], m4/threadlib.m4: AC_DEFINE([USE_SOLARIS_THREADS], [1], m4/threadlib.m4:AC_DEFINE([USE_SOLARIS_THREADS_WEAK], [1], m4/threadlib.m4:AC_DEFINE([USE_PTH_THREADS], [1], m4/threadlib.m4:AC_DEFINE([USE_PTH_THREADS_WEAK], [1], m4/threadlib.m4: AC_DEFINE([USE_WIN32_THREADS], [1], m4/unlocked-io.m4: AC_DEFINE([USE_UNLOCKED_IO], [1], m4/xattr.m4:AC_DEFINE_UNQUOTED([USE_XATTR], [$use_xattr], The first and last one of those should probably be 1, not $use_foo? Actually acl.m4 sets it to 1, not yes, so that should be working fine (I don't use ACL myself though). I can't figure out why it breaks on that machine though, I assume it works for a lot of people, and neither the m4 file nor cp.c has changed on those lines since xattr support was added... Disclaimer: this is gentoo ;). -- Mikael Magnusson
