Re: Suggestion for rm(1)
Keisial wrote: > Eric Blake wrote: >> 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. > > What about s/the contents/some contents/ ? > The impression of easy recovery is gone since the newbie wants the full > file. Since retrieving just part of a file is bad enough for sensitive > contents, > the user goes for shred in that case. > > Depending on filesystem, here "some" can go from 0 to 100% so it's > technically correct, too. I rather like this direction of description. Bob
Re: Suggestion for rm(1)
On 03/11/2010 04:38 PM, Keisial wrote:
>> 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.
>>
> What about s/the contents/some contents/ ?
I like it. It does indeed add another realm of caution to the user -
both the user that cares if even one block can be recovered (use of
shred is more important), and the user that cares whether the whole file
can be easily retrieved ('some' is weaker than 'the', and definitely
gives the desired connotation that it is not easy).
Now if someone would submit this rewording in actual patch format...
--
Eric Blake ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: Suggestion for rm(1)
Eric Blake wrote: 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. What about s/the contents/some contents/ ? The impression of easy recovery is gone since the newbie wants the full file. Since retrieving just part of a file is bad enough for sensitive contents, the user goes for shred in that case. Depending on filesystem, here "some" can go from 0 to 100% so it's technically correct, too.
Re: SU tool
Andreas Schwab wrote: > Bob Proulx writes: > > Andreas Schwab wrote: > >> Eric Blake writes: > >> > Coreutils is one of those packages, but most distros use another > >> > version. > >> > >> I wonder which are those distros. > > > > Debian is one such distro that uses su from the 'login' package. I > > will assume that Ubuntu is the same. And so on for the rest of the > > cousins on that side of the family. > > That's one. I know at least two that don't. Your point is taken. Without taking a comprehensive survey it would be difficult to determine which distro comprises "most" of the population. And that is practically impossible to do. Instead it would have been safer to say "many" there avoid the issue. Bob
Re: SU tool
Bob Proulx writes: > Andreas Schwab wrote: >> Eric Blake writes: >> > Coreutils is one of those packages, but most distros use another >> > version. >> >> I wonder which are those distros. > > Debian is one such distro that uses su from the 'login' package. I > will assume that Ubuntu is the same. And so on for the rest of the > cousins on that side of the family. That's one. I know at least two that don't. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: Suggestion for rm(1)
On 3/11/2010 7:37 AM, Andreas Schwab wrote: > Incidentally, due to the increasing use of SSD and their tendency not to > reuse recently used blocks it may become again easier in future to > recover data. Actually once TRIM support becomes common recovering deleted files on SSD will be impossible since the flash blocks will be erased rather than just being left unallocated. I think the man page should changed to state that the file *MAY* be recoverable using forensics. That should be sufficiently clear that it is not a secure erase, but recovery is not at all easy if it is possible at all.
Re: Suggestion for rm(1)
Andreas Schwab wrote: > Incidentally, due to the increasing use of SSD and their tendency not to > reuse recently used blocks it may become again easier in future to > recover data. That is an interesting observation. But it really depends upon the firmware used on the device. Not all SSDs operate the same and there are wide variations in implementation and resulting performance. Some vendors improve performance by aggressively making freed space available for rewrite. Support from the trim[1] command is critical for this function. (In short, you want it.) Also accessing any deleted blocks may require low level device specific diagnose instructions. So it is also possible that widespread use of SSDs in the future may make it increasingly more difficult to recover deleted files. Bob [1] http://en.wikipedia.org/wiki/TRIM
Re: SU tool
Andreas Schwab wrote: > Eric Blake writes: > > Coreutils is one of those packages, but most distros use another > > version. > > I wonder which are those distros. Debian is one such distro that uses su from the 'login' package. I will assume that Ubuntu is the same. And so on for the rest of the cousins on that side of the family. Bob
Re: [coreutils] [PATCH] maint: ignore *.xz files
Eric Blake wrote: > * .gitignore: Ignore *.xz created by 'make dist', now that we > no longer produce *.lzma. > --- > > Should patches go to bug-coreut...@... That's fine, or use the new coreutils-patches alias. > Is it worth keeping the .lzma ignores in place, or should I delete > those before pushing? Thanks. .lzma is obsolete, so please remove it. I'm assuming you've fixed the typo too, of course. ... > coreutils-*.tar.lzma > coreutils-*.tar.lzma.sig > +coreutils-*.tar.xz > +coreutils-*.tar.xz
Re: SU tool
Eric Blake writes: > Coreutils is one of those packages, but most distros use another > version. I wonder which are those distros. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: SU tool
On 03/11/2010 01:01 AM, islam said wrote: > Dear Sir, > Good Day. > > i'm using REDHAT Linux Server 9 and i noticed while using SU command the -l > option which is very useful. > I checked for this option in the SU tool installed with IBM AIX UNIX i > didn't find it. > So i'm asking you where can i find and download the source of the SU tool > installed in Linux REDHAT 9 so i can install it on IBM AIX UNIX. It is available from multiple packages. Coreutils is one of those packages, but most distros use another version. Therefore, if you are interested in using Coreutils' version of su, you need to specifically request it at configure time when compiling coreutils on your AIX machine: $ wget http://ftpmirror.gnu.org/coreutils/coreutils-8.4.tar.xz $ tar xJvf coreutils-8.4.tar.xz $ cd coreutils-8.4 $ ./configure --enable-install-program $ make $ make install will give you /usr/local/bin/su that understands -l -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: SU tool
On 11/03/10 08:01, islam said wrote:
> Dear Sir,
> Good Day.
>
> i'm using REDHAT Linux Server 9 and i noticed while using SU command the -l
> option which is very useful.
> I checked for this option in the SU tool installed with IBM AIX UNIX i
> didn't find it.
> So i'm asking you where can i find and download the source of the SU tool
> installed in Linux REDHAT 9 so i can install it on IBM AIX UNIX.
>
> Can't wait to your reply.
> Thank you in advance
>
rpm -qf $(which su) --qf="%{URL}\n" ->
http://www.gnu.org/software/coreutils/ ->
http://ftp.gnu.org/gnu/coreutils/
cheers,
Pádraig.
SU tool
Dear Sir, Good Day. i'm using REDHAT Linux Server 9 and i noticed while using SU command the -l option which is very useful. I checked for this option in the SU tool installed with IBM AIX UNIX i didn't find it. So i'm asking you where can i find and download the source of the SU tool installed in Linux REDHAT 9 so i can install it on IBM AIX UNIX. Can't wait to your reply. Thank you in advance
Re: [PATCH] sort: add --threads option to parallelize internal sort.
Pádraig Brady wrote:
> On 11/03/10 11:29, Chen Guo wrote:
>> How stupid of me:
>>> +int
>>
>>> +memcoll0 (const char *s1, size_t s1len, const char *s2, size_t s2len)
>>> +{
>>> + int diff;
>>> + if (!(s1len> 0&& s1[s1len] == '\0'))
>>> +abort ();
>>> + if (!(s2len> 0&& s2[s2len] == '\0'))
>>> +abort ();
>>
>> should obviously be s1[s1len - 1] and s2[s2len - 1].
>
> Right.
> I know Bruno suggestd it, but I wonder is abort() a bit drastic here?
> Perhaps something like this might be more general?
>
> if (s1len==0 && s2len==0)
> return 0
> else if (s1len==0)
> return 1;
> else if (s2len==0)
> return -1;
>
> Also s1len is a bit confusing as it's not the strlen()
> it's the size of the s1 buffer. I'd prefer s1size.
"s1len" bothered me for another reason: readability.
Please separatewordsforimprovedreadability.
i.e., s1_len or s1_size.
> I hope to do a full review soon.
Thanks!
Re: Suggestion for rm(1)
Bob Proulx writes: > 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. Incidentally, due to the increasing use of SSD and their tendency not to reuse recently used blocks it may become again easier in future to recover data. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: [PATCH] sort: add --threads option to parallelize internal sort.
On 11/03/10 11:29, Chen Guo wrote:
How stupid of me:
+int
+memcoll0 (const char *s1, size_t s1len, const char *s2, size_t s2len)
+{
+ int diff;
+ if (!(s1len> 0&& s1[s1len] == '\0'))
+abort ();
+ if (!(s2len> 0&& s2[s2len] == '\0'))
+abort ();
should obviously be s1[s1len - 1] and s2[s2len - 1].
Right.
I know Bruno suggestd it, but I wonder is abort() a bit drastic here?
Perhaps something like this might be more general?
if (s1len==0 && s2len==0)
return 0
else if (s1len==0)
return 1;
else if (s2len==0)
return -1;
Also s1len is a bit confusing as it's not the strlen()
it's the size of the s1 buffer. I'd prefer s1size.
I hope to do a full review soon.
thanks,
Pádraig.
Re: [PATCH] sort: add --threads option to parallelize internal sort.
How stupid of me:
> +int
> +memcoll0 (const char *s1, size_t s1len, const char *s2, size_t s2len)
> +{
> + int diff;
> + if (!(s1len > 0 && s1[s1len] == '\0'))
> +abort ();
> + if (!(s2len > 0 && s2[s2len] == '\0'))
> +abort ();
should obviously be s1[s1len - 1] and s2[s2len - 1].
Re: --enable-xattr gives #define USE_XATTR yes instead of 1
On 11/03/10 03:37, Mikael Magnusson wrote: 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 ;). Yes 8.4 has this issue. It was fixed with: http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=e489fd04d66000829f5458843970794eccacced8 cheers, Pádraig.
RE: Suggestion for rm(1)
Eric Blake wrote: > 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. +1 Have a nice day, Berny
