Re: shred bug? [was: Unidentified subject!]

On Sun, Feb 11, 2024 at 08:02:12AM +0100, to...@tuxteam.de wrote: What Thomas was trying to do is to get a cheap, fast random number generator. Shred seems to have such. You're better off with /dev/urandom, it's much easier to understand what it's trying to do, vs the rather baroque logic

Re: shred bug? [was: Unidentified subject!]

; could be a file, a pipe, a terminal (character device), etc. > > > > Why pick on 1? > > It's the definition. Standard input is FD 0, standard output is FD 1, > and standard error is FD 2. > > > . It demonstrates the shell syntax element required (&) in order t

Re: shred bug? [was: Unidentified subject!]

On Tue, Feb 13, 2024 at 01:03:44PM -0800, David Christensen wrote: > On 2/13/24 09:40, debian-u...@howorth.org.uk wrote: > > Greg Wooledge wrote: > > > > > Shred will determine the size of the file, then write data to the > > > file, rewind, write data again,

Re: shred bug? [was: Unidentified subject!]

On 2/13/24 16:00, David Christensen wrote: On 2/13/24 11:31, gene heskett wrote: Next experiment is a pair of 4T Silicon Power SSD's When they & the startech usb3 adapters arrive.  I'll get that NAS built for amanda yet. 2.5" SATA SSD's and SATA to USB adapter cables for $187.97 + $10.99 =

Re: shred bug? [was: Unidentified subject!]

On 2/13/24 09:40, debian-u...@howorth.org.uk wrote: Greg Wooledge wrote: Shred will determine the size of the file, then write data to the file, rewind, write data again, etc. On a traditional hard drive, that will overwrite the original private information. On modern devices, it may

Re: shred bug? [was: Unidentified subject!]

On 2/13/24 11:31, gene heskett wrote: Next experiment is a pair of 4T Silicon Power SSD's When they & the startech usb3 adapters arrive.  I'll get that NAS built for amanda yet. 2.5" SATA SSD's and SATA to USB adapter cables for $187.97 + $10.99 = $198.96 each set?

Re: shred bug? [was: Unidentified subject!]

On 2/13/24 14:44, Thomas Schmitt wrote: Hi, Gene Heskett wrote: Next experiment is a pair of 4T Silicon Power SSD's When f3 has (hopefully) given its OK, the topic of a full write-and-read test will come up again. I'm looking forward to all the spin-off topics. I'll have to admit it has

Re: shred bug? [was: Unidentified subject!]

Hi, Gene Heskett wrote: > Next experiment is a pair of 4T Silicon Power SSD's When f3 has (hopefully) given its OK, the topic of a full write-and-read test will come up again. I'm looking forward to all the spin-off topics. Have a nice day :) Thomas

Re: shred bug? [was: Unidentified subject!]

Hi, Greg Wooledge wrote: > Heh. Don't forget your own attempts to use a shredder as a PRNG stream. My original idea was to watch a minimal shred run by teeing its work into a checksummer. But then topic drift came in. So we got a farm show of random generators and a discussion about w

Re: shred bug? [was: Unidentified subject!]

On 2/13/24 12:56, Thomas Schmitt wrote: Hi, Greg Wooledge wrote: Let me write out the example again, but with the bug fixed, and then explain what each line does, [... lecture about advanced shell programming ...] And this all because Gene Heskett was adventurous enough to buy a cheap fake

Re: shred bug? [was: Unidentified subject!]

is all because Gene Heskett was adventurous enough to buy a cheap > fake USB disk. :)) Heh. Don't forget your own attempts to use a shredder as a PRNG stream. Shell redirections can be complicated, so this topic is going to come up once in a while. The example in the shred info page is fairly uni

Re: shred bug? [was: Unidentified subject!]

Hi, Greg Wooledge wrote: > Let me write out the example again, but with the bug fixed, and then > explain what each line does, [... lecture about advanced shell > programming ...] And this all because Gene Heskett was adventurous enough to buy a cheap fake USB disk. :)) Have a nice day :)

Re: shred bug? [was: Unidentified subject!]

Greg Wooledge wrote: > Shred will determine the size of the file, then write data to the > file, rewind, write data again, etc. On a traditional hard drive, > that will overwrite the original private information. On modern > devices, it may not. Thanks for the excellent explana

Re: shred bug? [was: Unidentified subject!]

finition. Standard input is FD 0, standard output is FD 1, and standard error is FD 2. > . It demonstrates the shell syntax element required (&) in order to > avoid truncating the file, rather than shred overwriting it. You are confused. You're making assumptions about shell syntax th

Re: shred bug? [was: Unidentified subject!]

t;’", though there could be a better name for ‘>’. > > You're assuming the program will be used from a shell. This is *usually* > going to be true, but nothing prevents you from writing a C program > which closes stdout, opens a file, ensures that it's using FD 1, > and then

Re: shred bug? [was: Unidentified subject!]

Hi, "info shred" says: > > > i=$(mktemp) > > > exec 3<>"$i" > > > rm -- "$i" > > > echo "Hello, world" >&3 > > > shred - >&3 > > > exec 3>- G

Re: shred bug? [was: Unidentified subject!]

On Tue, Feb 13, 2024 at 07:36:14AM -0500, Greg Wooledge wrote: > On Tue, Feb 13, 2024 at 07:15:48AM -0500, Greg Wooledge wrote: > > This is an obvious bug in the info page. I wonder how many years > > this has gone unnoticed. > > I've filed Bug#1063837 for it.

Re: shred bug? [was: Unidentified subject!]

On Tue, Feb 13, 2024 at 07:15:48AM -0500, Greg Wooledge wrote: > This is an obvious bug in the info page. I wonder how many years > this has gone unnoticed. I've filed Bug#1063837 for it.

Re: shred bug? [was: Unidentified subject!]

his is *usually* going to be true, but nothing prevents you from writing a C program which closes stdout, opens a file, ensures that it's using FD 1, and then calls "shred -". The documentation has to support this use case as well. > >A FILE of ‘-’ denotes standard output

Re: shred bug? [was: Unidentified subject!]

On Mon, Feb 12, 2024 at 10:07:45PM +0100, Thomas Schmitt wrote: > Hi, > > > https://en.wikipedia.org/wiki/Everything_is_a_file > > But, there is more than one kind of file. > > "All files are equal. > But some files are more equal than others." > > (George Orwell in his dystopic novel "Server

Re: shred bug? [was: Unidentified subject!]

here isn't. The documentation says: > > > > SYNOPSIS > >shred [OPTION]... FILE... > > > > DESCRIPTION > >Overwrite the specified FILE(s) repeatedly, in order to make it > > harder > >for even very expensive hardware pr

Re: shred bug? [was: Unidentified subject!]

On 12/02/2024 05:41, David Christensen wrote: Apparently, shred(1) has both an info(1) page (?) and a man(1) page. The obvious solution is to write one document that is complete and correct, and use it everywhere -- e.g. DRY. https://www.gnu.org/prep/standards/html_node/Man-Pages.html 6.9

Re: shred bug? [was: Unidentified subject!]

Hi, > https://en.wikipedia.org/wiki/Everything_is_a_file > But, there is more than one kind of file. "All files are equal. But some files are more equal than others." (George Orwell in his dystopic novel "Server Farm".) Have a nice day :) Thomas

Re: shred bug? [was: Unidentified subject!]

On 2/12/24 08:50, Curt wrote: On 2024-02-11, wrote: On Sun, Feb 11, 2024 at 09:54:24AM -0500, Greg Wooledge wrote: [...] If FILE is -, shred standard output. =20 In every sentence, the word FILE appears. There's nothing in there which says "you can operate on a non

Re: shred bug? [was: Unidentified subject!]

On Mon, Feb 12, 2024 at 04:50:50PM -, Curt wrote: > On 2024-02-11, wrote: > > > > > > On Sun, Feb 11, 2024 at 09:54:24AM -0500, Greg Wooledge wrote: > > > > [...] > > > >>If FILE is -, shred standard output. > >>=20 > &

Re: shred bug? [was: Unidentified subject!]

On 2024-02-11, wrote: > > > On Sun, Feb 11, 2024 at 09:54:24AM -0500, Greg Wooledge wrote: > > [...] > >> If FILE is -, shred standard output. >>=20 >> In every sentence, the word FILE appears. There's nothing in there >> which says "you c

Re: shred bug? [was: Unidentified subject!]

, fast random number generator. Shred seems to have such. Well... I certainly wouldn't call it a bug. Maybe a feature request. Still there's the discrepancy between doc and behaviour. There isn't. The documentation says: SYNOPSIS shred [OPTION]... FILE... I interpret the above line

Re: shred bug? [was: Unidentified subject!]

.@tuxteam.de wrote: > > > > [...] > > > > > > What Thomas was trying to do is to get a cheap, fast random number > > > > generator. Shred seems to have such. > > > > > > Well... I certainly wouldn't call it a bug. Maybe a feature request. > > > > Still th

Re: shred bug? [was: Unidentified subject!]

Hi, to...@tuxteam.de wrote: > Still there's the discrepancy between doc and behaviour. Depends at which documentation you look. Obviously stemming from https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=155175#36 i read in https://www.gnu.org/software/coreutils/manual/html_node/sh

Re: shred bug? [was: Unidentified subject!]

On Sun, Feb 11, 2024 at 09:54:24AM -0500, Greg Wooledge wrote: [...] >If FILE is -, shred standard output. > > In every sentence, the word FILE appears. There's nothing in there > which says "you can operate on a non-file". Point taken, yes. Cheers -- t sig

Re: shred bug? [was: Unidentified subject!]

a cheap, fast random number > > > generator. Shred seems to have such. > > > > Well... I certainly wouldn't call it a bug. Maybe a feature request. > > Still there's the discrepancy between doc and behaviour. There isn't. The documentation says: SYNOPSIS shred [OPTION]..

Re: shred bug? [was: Unidentified subject!]

On Sun, Feb 11, 2024 at 09:37:31AM -0500, Greg Wooledge wrote: > On Sun, Feb 11, 2024 at 08:02:12AM +0100, to...@tuxteam.de wrote: [...] > > What Thomas was trying to do is to get a cheap, fast random number > > generator. Shred seems to have such. > > Well... I certainly w

Re: shred bug? [was: Unidentified subject!]

On Sun, Feb 11, 2024 at 08:02:12AM +0100, to...@tuxteam.de wrote: > On Sat, Feb 10, 2024 at 07:10:54PM -0500, Greg Wooledge wrote: > > On Sat, Feb 10, 2024 at 04:05:21PM -0800, David Christensen wrote: > > > 2024-02-10 16:03:50 dpchrist@laalaa ~ > > > $ shred

Re: shred bug?

Hi, debian-u...@howorth.org.uk wrote: > Maybe it is unstated but mandatory to use -n 1 as well? > And optionally -s N? Naw. It just doesn't want to work pipes. Initially i tried with these options: shred -n 1 -s 1K -v - | sha256sum as preparation for a proposal to Gene Heskett

Re: shred bug? [was: Unidentified subject!]

David Christensen wrote: > On 2/10/24 16:10, Greg Wooledge wrote: > > On Sat, Feb 10, 2024 at 04:05:21PM -0800, David Christensen wrote: > >> 2024-02-10 16:03:50 dpchrist@laalaa ~ > >> $ shred -s 1K - | wc -c > >> shred: -: invalid file type > >> 0

Re: shred bug? [was: Unidentified subject!]

On Sat, Feb 10, 2024 at 07:10:54PM -0500, Greg Wooledge wrote: > On Sat, Feb 10, 2024 at 04:05:21PM -0800, David Christensen wrote: > > 2024-02-10 16:03:50 dpchrist@laalaa ~ > > $ shred -s 1K - | wc -c > > shred: -: invalid file type > > 0 > > > > > >

Re: shred bug? [was: Unidentified subject!]

On 2/10/24 16:10, Greg Wooledge wrote: On Sat, Feb 10, 2024 at 04:05:21PM -0800, David Christensen wrote: 2024-02-10 16:03:50 dpchrist@laalaa ~ $ shred -s 1K - | wc -c shred: -: invalid file type 0 It looks like a shred(1) needs a bug report. I'm confused what you expected this command

Re: shred bug? [was: Unidentified subject!]

On Sat, Feb 10, 2024 at 04:05:21PM -0800, David Christensen wrote: > 2024-02-10 16:03:50 dpchrist@laalaa ~ > $ shred -s 1K - | wc -c > shred: -: invalid file type > 0 > > > It looks like a shred(1) needs a bug report. I'm confused what you expected this command to do. Y

Re: shred bug? [was: Unidentified subject!]

On 2/10/24 04:40, to...@tuxteam.de wrote: On Sat, Feb 10, 2024 at 11:38:21AM +0100, Thomas Schmitt wrote: [...] But shred(1) on Debian 11 refuses on "-" contrary to its documentation: shred: -: invalid file type A non-existing file path causes "No such file or directory"

Re: shred bug?

ver the code about the connection to an old graphics > algorithm (Bresenham's Algorithm) and how shred produces a random pattern > at all. This [1] perhaps? It's not a good random generator (and not crypto, by a long stretch) but it's pretty well equidistributed, ain't it? Ch

Re: shred bug?

Hi, to...@tuxteam.de wrote: > Ah, it seems to be this one, from 2002: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=155175 So it's not a bug but a feature. :( I'm riddling over the code about the connection to an old graphics algorithm (Bresenham's Algorithm) and how shred pr

Re: shred bug?

On 2/10/24 08:32, Thomas Schmitt wrote: Hi, i wrote: shred: -: invalid file type to...@tuxteam.de wrote: Hmm. This looks like a genuine bug: the man page mentions it. Even the help text in https://sources.debian.org/src/coreutils/9.4-3/src/shred.c/ says If FILE is -, shred

Re: shred bug?

Hi, i wrote: > > shred: -: invalid file type to...@tuxteam.de wrote: > Hmm. This looks like a genuine bug: the man page mentions it. Even the help text in https://sources.debian.org/src/coreutils/9.4-3/src/shred.c/ says If FILE is -, shred standard output. The name "-&

Re: shred bug? [was: Unidentified subject!]

On Sat, Feb 10, 2024 at 01:40:35PM +0100, to...@tuxteam.de wrote: > On Sat, Feb 10, 2024 at 11:38:21AM +0100, Thomas Schmitt wrote: > > [...] > > > But shred(1) on Debian 11 refuses on "-" contrary to its documentation: > > shred: -: invalid file type &

shred bug? [was: Unidentified subject!]

On Sat, Feb 10, 2024 at 11:38:21AM +0100, Thomas Schmitt wrote: [...] > But shred(1) on Debian 11 refuses on "-" contrary to its documentation: > shred: -: invalid file type > A non-existing file path causes "No such file or directory". Hmm. This looks lik

Re: Récursivité - shred

Sylvain Sauvage a écrit, mardi 6 novembre 2007, à 00:19 : [...] Sans -n, xargs lance un seul processus pour tous les arguments. Pas tout à fait : xargs découpe la suite des arguments en paquets selon les limitations du shell : $ echo {1..123456} | xargs echo | sed -e 's/ .* / ... /' 1 ...

Re: Récursivité - shred

Jacques L'helgoualc'h, mardi 6 novembre 2007, 10:03:43 CET Sylvain Sauvage a écrit, mardi 6 novembre 2007, à 00:19 : [...] Sans -n, xargs lance un seul processus pour tous les arguments. Pas tout à fait : xargs découpe la suite des arguments en paquets selon les limitations du

Re: Récursivité - shred

Sylvain Sauvage a écrit, mardi 6 novembre 2007, à 12:13 : [...] Pas tout à fait ;o) : xargs découpe la suite des arguments en paquets selon la valeur de l???option -s (nombre de caractères de la ligne), laquelle est par défaut 131072, y compris les variables d???environnement, donc, en

Taille de la ligne de commande, était: Re: Récursivité - shred

Jacques L'helgoualc'h, mardi 6 novembre 2007, 12:49:12 CET Sylvain Sauvage a écrit, mardi 6 novembre 2007, à 12:13 : [...] Pas tout à fait ;o) : xargs découpe la suite des arguments en paquets selon la valeur de l???option -s (nombre de caractères de la ligne), laquelle est par défaut

Re: Taille de la ligne de c ommande, était: Re: Récursivité - shred

Sylvain Sauvage a écrit, mardi 6 novembre 2007, à 17:13 : [...] Ensuite, POSIX.2 demande à ce que l???on conserve un marge de 2048 octets¹. Ah, voilà ! Je me demandais si autre chose que la sortie de « env » pouvait être transmis... [...] Il manque encore 2. Or, d???après les sources

Re: Récursivité - shred

François Boisson a écrit : Le Sun, 04 Nov 2007 08:01:50 -0800 [EMAIL PROTECTED] a écrit: Bonjour, Comment fait-on pour utiliser la commande shred sur une arborescence. $ find . -type f | xargs -n 1 shred Y-a t'il une différence avec l'utilisation de l'option -exec de find ? $ find

Re: Récursivit é - shred

On Mon, Nov 05, 2007 at 02:06:56PM -0800, geoffroy wrote: $ find . -type f | xargs -n 1 shred Appelle 1 fois shred sur 1000 fichiers... Y-a t'il une différence avec l'utilisation de l'option -exec de find ? $ find . -type f -exec shred '{}' \; Appelle 1000 fois shred sur 1 fichier

Re: Récursivité - shred

geoffroy, lundi 5 novembre 2007, 14:06:56 CET François Boisson a écrit : Le Sun, 04 Nov 2007 08:01:50 -0800 [EMAIL PROTECTED] a écrit: Bonjour, Comment fait-on pour utiliser la commande shred sur une arborescence. $ find . -type f | xargs -n 1 shred Y-a t'il une

Re: [merci] Récursivité - shred

Sylvain Sauvage a écrit : geoffroy, lundi 5 novembre 2007, 14:06:56 CET François Boisson a écrit : Le Sun, 04 Nov 2007 08:01:50 -0800 [EMAIL PROTECTED] a écrit: Bonjour, Comment fait-on pour utiliser la commande shred sur une arborescence. $ find . -type f | xargs -n 1 shred Y-a t'il

Récursivité - shred

Bonjour, Comment fait-on pour utiliser la commande shred sur une arborescence. Merci. -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs From et Reply-To: To UNSUBSCRIBE, email to [EMAIL

Re: Récursivité - shred

Le Sun, 04 Nov 2007 08:01:50 -0800 [EMAIL PROTECTED] a écrit: Bonjour, Comment fait-on pour utiliser la commande shred sur une arborescence. $ find . -type f | xargs -n 1 shred par exemple... François Boisson -- Lisez la FAQ de la liste avant de poser une question : http

Re: Shred Iterations

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/18/07 00:13, Tyler MacDonald wrote: Masatran, R. Deepak [EMAIL PROTECTED] wrote: Why does shred have multiple iterations (25) as the default option? I see no point in overwriting more than once. Is not sudo shred --iterations=1

Re: Shred Iterations

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/18/07 00:08, Masatran, R. Deepak wrote: Why does shred have multiple iterations (25) as the default option? I see no point in overwriting more than once. Is not sudo shred --iterations=1 --verbose /dev/sda sufficient

Shred Iterations

Why does shred have multiple iterations (25) as the default option? I see no point in overwriting more than once. Is not sudo shred --iterations=1 --verbose /dev/sda sufficient? -- Masatran, R. Deepak http://research.iiit.ac.in/~masatran/ pgpAfHNay75mA.pgp Description: PGP signature

Re: Shred Iterations

Masatran, R. Deepak [EMAIL PROTECTED] wrote: Why does shred have multiple iterations (25) as the default option? I see no point in overwriting more than once. Is not sudo shred --iterations=1 --verbose /dev/sda sufficient? Not if you *REALLY* want to get rid of something.. then again

ReiserFS and shred

I wanted to shred some files on my ReiserFS partition. But then I saw the message on the bottom of the --help printout saying: CAUTION: Note that shred relies on a very important assumption: that the filesystem overwrites data in place. This is the traditional way to do things

Re: shred

also sprach harsha (on Tue, 14 Aug 2001 12:10:46AM +0530): There is this option of shreding of a file in KDE What exactly does it do? The progress bar shows making 36 passes if I delete about 150k file. it most likely overwrites the file several times with alternating patterns of 0's and 1's

Re: shred

man shred. It's a secure rm, overwriting with zeros and other stuff... On Tue, 14 Aug 2001, harsha wrote: Hi, There is this option of shreding of a file in KDE What exactly does it do? The progress bar shows making 35 passes if I delete about 150k file. regards harsha -- Galt's sci-fi

Re: shred

On Mon, 13 Aug 2001, Martin F. Krafft wrote: also sprach harsha (on Tue, 14 Aug 2001 12:10:46AM +0530): There is this option of shreding of a file in KDE What exactly does it do? The progress bar shows making 36 passes if I delete about 150k file. it most likely overwrites the file

Re: shred

on Mon, Aug 13, 2001 at 11:17:50PM -0600, Rick Macdonald ([EMAIL PROTECTED]) wrote: On Mon, 13 Aug 2001, Martin F. Krafft wrote: also sprach harsha (on Tue, 14 Aug 2001 12:10:46AM +0530): There is this option of shreding of a file in KDE What exactly does it do? The progress bar shows

shred

Hi, There is this option of shreding of a file in KDE What exactly does it do? The progress bar shows making 35 passes if I delete about 150k file. regards harsha