Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.user > #267123 > unrolled thread
| Started by | gene heskett <gheskett@shentel.net> |
|---|---|
| First post | 2024-02-07 21:40 +0100 |
| Last post | 2024-02-09 14:20 +0100 |
| Articles | 20 on this page of 98 — 20 participants |
Back to article view | Back to linux.debian.user
Unidentified subject! gene heskett <gheskett@shentel.net> - 2024-02-07 21:40 +0100
Re: Unidentified subject! Stefan Monnier <monnier@iro.umontreal.ca> - 2024-02-08 05:30 +0100
Re: Unidentified subject! gene heskett <gheskett@shentel.net> - 2024-02-10 11:00 +0100
Re: Unidentified subject! "Thomas Schmitt" <scdbackup@gmx.net> - 2024-02-10 11:40 +0100
shred bug? [was: Unidentified subject!] <tomas@tuxteam.de> - 2024-02-10 13:50 +0100
Re: shred bug? [was: Unidentified subject!] tomas@tuxteam.de - 2024-02-10 14:00 +0100
Re: shred bug? "Thomas Schmitt" <scdbackup@gmx.net> - 2024-02-10 15:00 +0100
Re: shred bug? <tomas@tuxteam.de> - 2024-02-10 15:40 +0100
Re: shred bug? Gremlin <scott-andrews@columbus.rr.com> - 2024-02-10 14:40 +0100
Re: shred bug? "Thomas Schmitt" <scdbackup@gmx.net> - 2024-02-10 14:40 +0100
Re: shred bug? [was: Unidentified subject!] David Christensen <dpchrist@holgerdanske.com> - 2024-02-11 01:10 +0100
Re: shred bug? [was: Unidentified subject!] Greg Wooledge <greg@wooledge.org> - 2024-02-11 01:20 +0100
Re: shred bug? [was: Unidentified subject!] David Christensen <dpchrist@holgerdanske.com> - 2024-02-11 01:30 +0100
Re: shred bug? [was: Unidentified subject!] debian-user@howorth.org.uk - 2024-02-11 14:00 +0100
Re: shred bug? "Thomas Schmitt" <scdbackup@gmx.net> - 2024-02-11 14:30 +0100
Re: shred bug? [was: Unidentified subject!] <tomas@tuxteam.de> - 2024-02-11 08:10 +0100
Re: shred bug? [was: Unidentified subject!] Greg Wooledge <greg@wooledge.org> - 2024-02-11 15:40 +0100
Re: shred bug? [was: Unidentified subject!] <tomas@tuxteam.de> - 2024-02-11 15:50 +0100
Re: shred bug? [was: Unidentified subject!] Greg Wooledge <greg@wooledge.org> - 2024-02-11 16:00 +0100
Re: shred bug? [was: Unidentified subject!] <tomas@tuxteam.de> - 2024-02-11 16:00 +0100
Re: shred bug? [was: Unidentified subject!] Greg Wooledge <greg@wooledge.org> - 2024-02-12 18:00 +0100
Re: shred bug? [was: Unidentified subject!] Curt <curty@free.fr> - 2024-02-12 18:00 +0100
Re: shred bug? [was: Unidentified subject!] David Christensen <dpchrist@holgerdanske.com> - 2024-02-12 22:00 +0100
Re: shred bug? [was: Unidentified subject!] "Thomas Schmitt" <scdbackup@gmx.net> - 2024-02-12 22:10 +0100
Re: shred bug? [was: Unidentified subject!] <tomas@tuxteam.de> - 2024-02-13 06:50 +0100
Re: shred bug? [was: Unidentified subject!] David Wright <deblis@lionunicorn.co.uk> - 2024-02-11 16:30 +0100
Re: shred bug? [was: Unidentified subject!] Greg Wooledge <greg@wooledge.org> - 2024-02-13 13:20 +0100
Re: shred bug? [was: Unidentified subject!] Greg Wooledge <greg@wooledge.org> - 2024-02-13 13:40 +0100
Re: shred bug? [was: Unidentified subject!] <tomas@tuxteam.de> - 2024-02-13 13:50 +0100
Re: shred bug? [was: Unidentified subject!] "Thomas Schmitt" <scdbackup@gmx.net> - 2024-02-13 14:00 +0100
Re: shred bug? [was: Unidentified subject!] David Wright <deblis@lionunicorn.co.uk> - 2024-02-13 16:40 +0100
Re: shred bug? [was: Unidentified subject!] Greg Wooledge <greg@wooledge.org> - 2024-02-13 17:30 +0100
Re: shred bug? [was: Unidentified subject!] debian-user@howorth.org.uk - 2024-02-13 18:50 +0100
Re: shred bug? [was: Unidentified subject!] David Christensen <dpchrist@holgerdanske.com> - 2024-02-13 22:10 +0100
Re: shred bug? [was: Unidentified subject!] <tomas@tuxteam.de> - 2024-02-14 06:50 +0100
Re: shred bug? [was: Unidentified subject!] "Thomas Schmitt" <scdbackup@gmx.net> - 2024-02-13 19:00 +0100
Re: shred bug? [was: Unidentified subject!] Greg Wooledge <greg@wooledge.org> - 2024-02-13 20:00 +0100
Re: shred bug? [was: Unidentified subject!] "Thomas Schmitt" <scdbackup@gmx.net> - 2024-02-13 20:40 +0100
Re: shred bug? [was: Unidentified subject!] gene heskett <gheskett@shentel.net> - 2024-02-13 20:40 +0100
Re: shred bug? [was: Unidentified subject!] "Thomas Schmitt" <scdbackup@gmx.net> - 2024-02-13 20:50 +0100
Re: shred bug? [was: Unidentified subject!] gene heskett <gheskett@shentel.net> - 2024-02-13 21:30 +0100
Re: shred bug? [was: Unidentified subject!] David Christensen <dpchrist@holgerdanske.com> - 2024-02-13 22:10 +0100
Re: shred bug? [was: Unidentified subject!] gene heskett <gheskett@shentel.net> - 2024-02-13 22:50 +0100
Re: shred bug? [was: Unidentified subject!] David Wright <deblis@lionunicorn.co.uk> - 2024-02-15 06:40 +0100
Re: shred bug? [was: Unidentified subject!] David Christensen <dpchrist@holgerdanske.com> - 2024-02-11 23:50 +0100
Re: shred bug? [was: Unidentified subject!] Max Nikulin <manikulin@gmail.com> - 2024-02-13 03:40 +0100
Re: shred bug? [was: Unidentified subject!] "Thomas Schmitt" <scdbackup@gmx.net> - 2024-02-11 16:30 +0100
Re: shred bug? [was: Unidentified subject!] Michael Stone <mstone@debian.org> - 2024-02-16 16:00 +0100
Re: Unidentified subject! gene heskett <gheskett@shentel.net> - 2024-02-10 18:50 +0100
Re: Unidentified subject! "Thomas Schmitt" <scdbackup@gmx.net> - 2024-02-10 19:40 +0100
Re: Unidentified subject! gene heskett <gheskett@shentel.net> - 2024-02-10 20:30 +0100
Re: Unidentified subject! David Christensen <dpchrist@holgerdanske.com> - 2024-02-11 00:50 +0100
Re: Unidentified subject! "Thomas Schmitt" <scdbackup@gmx.net> - 2024-02-11 09:10 +0100
Re: Unidentified subject! David Christensen <dpchrist@holgerdanske.com> - 2024-02-11 21:50 +0100
Re: Unidentified subject! David Christensen <dpchrist@holgerdanske.com> - 2024-02-11 00:40 +0100
Re: Unidentified subject! "Thomas Schmitt" <scdbackup@gmx.net> - 2024-02-11 09:20 +0100
Re: Unidentified subject! David Christensen <dpchrist@holgerdanske.com> - 2024-02-11 11:10 +0100
Fast Random Data Generation (Was: Re: Unidentified subject!) Linux-Fan <Ma_Sys.ma@web.de> - 2024-02-11 11:30 +0100
Re: Fast Random Data Generation "Thomas Schmitt" <scdbackup@gmx.net> - 2024-02-11 12:30 +0100
Re: Fast Random Data Generation (Was: Re: Unidentified subject!) Gremlin <scott-andrews@columbus.rr.com> - 2024-02-11 13:20 +0100
Re: Fast Random Data Generation (Was: Re: Unidentified subject!) David Christensen <dpchrist@holgerdanske.com> - 2024-02-12 07:20 +0100
Re: Fast Random Data Generation (Was: Re: Unidentified subject!) Linux-Fan <Ma_Sys.ma@web.de> - 2024-02-12 17:40 +0100
Re: Fast Random Data Generation (Was: Re: Unidentified subject!) David Christensen <dpchrist@holgerdanske.com> - 2024-02-12 22:30 +0100
Re: Fast Random Data Generation (Was: Re: Unidentified subject!) Linux-Fan <Ma_Sys.ma@web.de> - 2024-02-13 18:40 +0100
Re: Fast Random Data Generation (Was: Re: Unidentified subject!) Jeffrey Walton <noloader@gmail.com> - 2024-02-12 22:30 +0100
Re: Unidentified subject! "Thomas Schmitt" <scdbackup@gmx.net> - 2024-02-11 12:20 +0100
Re: Unidentified subject! Jeffrey Walton <noloader@gmail.com> - 2024-02-11 16:20 +0100
Re: Unidentified subject! David Christensen <dpchrist@holgerdanske.com> - 2024-02-11 23:00 +0100
Re: Unidentified subject! Stefan Monnier <monnier@iro.umontreal.ca> - 2024-02-10 15:40 +0100
Things I don't touch with a 3.048m barge pole: USB storage (Was Re: Unidentified subject!) Andy Smith <andy@strugglers.net> - 2024-02-08 16:40 +0100
Re: Things I don't touch with a 3.048m barge pole: USB storage (Was Re: Unidentified subject!) Gremlin <scott-andrews@columbus.rr.com> - 2024-02-08 17:20 +0100
Re: Things I don't touch with a 3.048m barge pole: USB storage (Was Re: Unidentified subject!) Andy Smith <andy@strugglers.net> - 2024-02-08 17:30 +0100
Re: Things I don't touch with a 3.048m barge pole: USB storage (WasRe: Unidentified subject!) gene heskett <gheskett@shentel.net> - 2024-02-09 09:50 +0100
Re: Things I don't touch with a 3.048m barge pole: USB storage (Was Re: Unidentified subject!) Ralph Aichinger <ra@h5.or.at> - 2024-02-08 18:00 +0100
Re: Things I don't touch with a 3.048m barge pole: USB storage (Was Re: Unidentified subject!) Jeffrey Walton <noloader@gmail.com> - 2024-02-08 20:30 +0100
Re: Things I don't touch with a 3.048m barge pole: USB storage (Was Re: Unidentified subject!) Andy Smith <andy@strugglers.net> - 2024-02-08 21:50 +0100
Re: Things I don't touch with a 3.048m barge pole: USB storage (Was Re: Unidentified subject!) Andy Smith <andy@strugglers.net> - 2024-02-08 21:50 +0100
Re: Things I don't touch with a 3.048m barge pole: USB storage (Was Re: Unidentified subject!) Gremlin <scott-andrews@columbus.rr.com> - 2024-02-08 22:00 +0100
Re: Things I don't touch with a 3.048m barge pole: USB storage (Was Re: Unidentified subject!) Andy Smith <andy@strugglers.net> - 2024-02-08 22:20 +0100
Re: Things I don't touch with a 3.048m barge pole: USB storage (Was Re: Unidentified subject!) Andy Smith <andy@strugglers.net> - 2024-02-08 22:30 +0100
Re: Things I don't touch with a 3.048m barge pole: USB storage (Was Re: Unidentified subject!) Gremlin <scott-andrews@columbus.rr.com> - 2024-02-08 23:10 +0100
Re: Things I don't touch with a 3.048m barge pole: USB storage (Was Re: Unidentified subject!) Gremlin <scott-andrews@columbus.rr.com> - 2024-02-08 22:30 +0100
Re: Things I don't touch with a 3.048m barge pole: USB storage (WasRe: Unidentified subject!) gene heskett <gheskett@shentel.net> - 2024-02-09 14:00 +0100
Re: Things I don't touch with a 3.048m barge pole "Thomas Schmitt" <scdbackup@gmx.net> - 2024-02-09 14:50 +0100
Re: Things I don't touch with a 3.048m barge pole: USB storage (WasRe: Unidentified subject!) David Christensen <dpchrist@holgerdanske.com> - 2024-02-10 07:00 +0100
Re: Things I don't touch with a 3.048m barge pole: USB storage(WasRe: Unidentified subject!) gene heskett <gheskett@shentel.net> - 2024-02-10 18:40 +0100
Re: Things I don't touch with a 3.048m barge pole: USB storage (Was Re: Unidentified subject!) Andy Smith <andy@strugglers.net> - 2024-02-08 21:40 +0100
Re: Things I don't touch with a 3.048m barge pole: USB storage (Was Re: Unidentified subject!) Arno Lehmann <al@its-lehmann.de> - 2024-02-09 09:50 +0100
Re: Things I don't touch with a 3.048m barge pole: USB storage (Was Re: Unidentified subject!) Max Nikulin <manikulin@gmail.com> - 2024-02-08 18:30 +0100
Re: Things I don't touch with a 3.048m barge pole: USB storage (Was Re: Unidentified subject!) Andy Smith <andy@strugglers.net> - 2024-02-08 21:40 +0100
Re: Things I don't touch with a 3.048m barge pole: USB storage (Was Re: Unidentified subject!) Gremlin <scott-andrews@columbus.rr.com> - 2024-02-08 22:10 +0100
Re: Things I don't touch with a 3.048m barge pole: USB storage (Was Re: Unidentified subject!) Andy Smith <andy@strugglers.net> - 2024-02-08 22:20 +0100
Re: Unidentified subject! Richmond <dnomhcir@gmx.com> - 2024-02-08 23:50 +0100
Re: Unidentified subject! Stefan Monnier <monnier@iro.umontreal.ca> - 2024-02-09 00:10 +0100
Re: Unidentified subject! Charles Curley <charlescurley@charlescurley.com> - 2024-02-09 00:50 +0100
Re: Unidentified subject! Richmond <dnomhcir@gmx.com> - 2024-02-09 05:50 +0100
Re: Unidentified flying subject! Charles Curley <charlescurley@charlescurley.com> - 2024-02-09 07:50 +0100
Re: Unidentified flying subject! Richmond <dnomhcir@gmx.com> - 2024-02-09 14:20 +0100
Page 1 of 5 [1] 2 3 4 5 Next page →
| From | gene heskett <gheskett@shentel.net> |
|---|---|
| Date | 2024-02-07 21:40 +0100 |
| Subject | Unidentified subject! |
| Message-ID | <I4WS5-8AFZ-17@gated-at.bofh.it> |
Well the 2T memory everybody was curious about 3 weeks ago got here early. From dmesg after plugging one in: [629240.916163] usb 1-2: new high-speed USB device number 39 using xhci_hcd [629241.066221] usb 1-2: New USB device found, idVendor=048d, idProduct=1234, bcdDevice= 2.00 [629241.066234] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [629241.066239] usb 1-2: Product: Disk 3.0 [629241.066242] usb 1-2: Manufacturer: USB [629241.066246] usb 1-2: SerialNumber: 2697241127107725123 [629241.069485] usb-storage 1-2:1.0: USB Mass Storage device detected [629241.074187] scsi host37: usb-storage 1-2:1.0 [629242.100738] scsi 37:0:0:0: Direct-Access SSD 3.0 2.00 PQ: 0 ANSI: 4 [629242.100959] sd 37:0:0:0: Attached scsi generic sg13 type 0 [629242.101190] sd 37:0:0:0: [sdm] 4096000000 512-byte logical blocks: (2.10 TB/1.91 TiB) [629242.101289] sd 37:0:0:0: [sdm] Write Protect is off [629242.101290] sd 37:0:0:0: [sdm] Mode Sense: 03 00 00 00 [629242.101409] sd 37:0:0:0: [sdm] No Caching mode page found [629242.101410] sd 37:0:0:0: [sdm] Assuming drive cache: write through [629242.103927] sdm: sdm1 [629242.104047] sd 37:0:0:0: [sdm] Attached SCSI disk gene@coyote: Looks like a reasonable facsimile of a 2T disk to me. Cheers, Gene Heskett, CET. -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author, 1940) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis
[toc] | [next] | [standalone]
| From | Stefan Monnier <monnier@iro.umontreal.ca> |
|---|---|
| Date | 2024-02-08 05:30 +0100 |
| Message-ID | <I54cV-8Fhu-1@gated-at.bofh.it> |
| In reply to | #267123 |
> Well the 2T memory everybody was curious about 3 weeks ago got here early.
>
> From dmesg after plugging one in:
> [629240.916163] usb 1-2: new high-speed USB device number 39 using xhci_hcd
> [629241.066221] usb 1-2: New USB device found, idVendor=048d,
> idProduct=1234, bcdDevice= 2.00
> [629241.066234] usb 1-2: New USB device strings: Mfr=1, Product=2,
> SerialNumber=3
> [629241.066239] usb 1-2: Product: Disk 3.0
> [629241.066242] usb 1-2: Manufacturer: USB
> [629241.066246] usb 1-2: SerialNumber: 2697241127107725123
> [629241.069485] usb-storage 1-2:1.0: USB Mass Storage device detected
> [629241.074187] scsi host37: usb-storage 1-2:1.0
> [629242.100738] scsi 37:0:0:0: Direct-Access SSD 3.0 2.00
> PQ: 0 ANSI: 4
> [629242.100959] sd 37:0:0:0: Attached scsi generic sg13 type 0
> [629242.101190] sd 37:0:0:0: [sdm] 4096000000 512-byte logical blocks: (2.10
> TB/1.91 TiB)
> [629242.101289] sd 37:0:0:0: [sdm] Write Protect is off
> [629242.101290] sd 37:0:0:0: [sdm] Mode Sense: 03 00 00 00
> [629242.101409] sd 37:0:0:0: [sdm] No Caching mode page found
> [629242.101410] sd 37:0:0:0: [sdm] Assuming drive cache: write through
> [629242.103927] sdm: sdm1
> [629242.104047] sd 37:0:0:0: [sdm] Attached SCSI disk
> gene@coyote:
>
> Looks like a reasonable facsimile of a 2T disk to me.
AFAIK the bogus 128TB drives do properly report such ridiculous sizes:
the reality only hits when you try to actually store that amount of
information on them.
[ I'm not sure how it works under the hood, but since SSDs store their
data "anywhere" in the flash, they can easily pretend to have any size
they want, and allocate the physical flash blocks only on-the-fly as
logical blocks are being written.
Also, some Flash controllers use compression, so if you store data
that compresses well, they can let you store a lot more than if you
store already compressed data. ]
IOW, to really check, try to save 2TB of videos (or other already
compressed data), and then try and read it back.
Stefan
[toc] | [prev] | [next] | [standalone]
| From | gene heskett <gheskett@shentel.net> |
|---|---|
| Date | 2024-02-10 11:00 +0100 |
| Message-ID | <I5Sjn-9bw1-3@gated-at.bofh.it> |
| In reply to | #267127 |
On 2/7/24 23:28, Stefan Monnier wrote: >> Well the 2T memory everybody was curious about 3 weeks ago got here early. >> >> From dmesg after plugging one in: >> [629240.916163] usb 1-2: new high-speed USB device number 39 using xhci_hcd >> [629241.066221] usb 1-2: New USB device found, idVendor=048d, >> idProduct=1234, bcdDevice= 2.00 >> [629241.066234] usb 1-2: New USB device strings: Mfr=1, Product=2, >> SerialNumber=3 >> [629241.066239] usb 1-2: Product: Disk 3.0 >> [629241.066242] usb 1-2: Manufacturer: USB >> [629241.066246] usb 1-2: SerialNumber: 2697241127107725123 >> [629241.069485] usb-storage 1-2:1.0: USB Mass Storage device detected >> [629241.074187] scsi host37: usb-storage 1-2:1.0 >> [629242.100738] scsi 37:0:0:0: Direct-Access SSD 3.0 2.00 >> PQ: 0 ANSI: 4 >> [629242.100959] sd 37:0:0:0: Attached scsi generic sg13 type 0 >> [629242.101190] sd 37:0:0:0: [sdm] 4096000000 512-byte logical blocks: (2.10 >> TB/1.91 TiB) >> [629242.101289] sd 37:0:0:0: [sdm] Write Protect is off >> [629242.101290] sd 37:0:0:0: [sdm] Mode Sense: 03 00 00 00 >> [629242.101409] sd 37:0:0:0: [sdm] No Caching mode page found >> [629242.101410] sd 37:0:0:0: [sdm] Assuming drive cache: write through >> [629242.103927] sdm: sdm1 >> [629242.104047] sd 37:0:0:0: [sdm] Attached SCSI disk >> gene@coyote: >> >> Looks like a reasonable facsimile of a 2T disk to me. > > AFAIK the bogus 128TB drives do properly report such ridiculous sizes: > the reality only hits when you try to actually store that amount of > information on them. > > [ I'm not sure how it works under the hood, but since SSDs store their > data "anywhere" in the flash, they can easily pretend to have any size > they want, and allocate the physical flash blocks only on-the-fly as > logical blocks are being written. > Also, some Flash controllers use compression, so if you store data > that compresses well, they can let you store a lot more than if you > store already compressed data. ] > > IOW, to really check, try to save 2TB of videos (or other already > compressed data), and then try and read it back. > Sounds like a lawsuit to me. If I can get Alexanders script from a few days back to run. Is bash not actually bash these days? It is not doing for loops for me. Thanks for the heads up, Stefan. > > Stefan > > . Cheers, Gene Heskett, CET. -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author, 1940) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis
[toc] | [prev] | [next] | [standalone]
| From | "Thomas Schmitt" <scdbackup@gmx.net> |
|---|---|
| Date | 2024-02-10 11:40 +0100 |
| Message-ID | <I5SW6-9bXT-3@gated-at.bofh.it> |
| In reply to | #267218 |
Hi, Gene Heskett wrote: > Is bash not actually bash these days? It is not doing for loops for me. Come on Gene, be no sophie. Copy+paste your failing line here. :)) IIRC the for-loop in question writes several copies of the same file. ( https://lists.debian.org/debian-user/2024/02/msg00318.html ) Others already pointed out that this invites for firmware scams like deduplication or silent overwriting of older data. I would vote for a filesystem killer like shred -n 1 -s 2047999968K -v - | tee /dev/sdm1 | sha256sum dd if=/dev/sdm1 bs=32K count=63999999 skip=32 | sha256sum 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". The filesystem killer aspect could be removed by creating large data files in the readily partitioned and formatted filesystems of the disk. (Replace "/dev/sdm1" by "/where/mounted/random_test_file" and reduce the numbers 2047999968K and bs=32K count=63999999 to what you expect to fit into the filesystem. Like 2000000000K and bs=32K count=62500000. Ask df for storage capacities.) But there needs to be a fast pseudo-random byte stream (which shred would provide if i could talk it into writing to stdout) which you can split for the device and for sha256sum. I have an own weak-random generator, but shred beats it by a factor of 10 when writing to /dev/null. Have a nice day :) Thomas
[toc] | [prev] | [next] | [standalone]
| From | <tomas@tuxteam.de> |
|---|---|
| Date | 2024-02-10 13:50 +0100 |
| Subject | shred bug? [was: Unidentified subject!] |
| Message-ID | <I5UXT-9d6R-3@gated-at.bofh.it> |
| In reply to | #267220 |
[Multipart message — attachments visible in raw view] — view raw
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 like a genuine bug: the man page mentions it. Also, /dev/stdout as target runs into the very same problem. Cheers -- t
[toc] | [prev] | [next] | [standalone]
| From | tomas@tuxteam.de |
|---|---|
| Date | 2024-02-10 14:00 +0100 |
| Subject | Re: shred bug? [was: Unidentified subject!] |
| Message-ID | <I5V7z-9da9-5@gated-at.bofh.it> |
| In reply to | #267223 |
[Multipart message — attachments visible in raw view] — view raw
On Sat, Feb 10, 2024 at 01:40:35PM +0100, tomas@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". > > Hmm. This looks like a genuine bug: the man page mentions it. > > Also, /dev/stdout as target runs into the very same problem. Ah, it seems to be this one, from 2002: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=155175 which is archived. The argument seems to be that shred on stdout doesn't make any sense, because the shell would truncate the file anyway when you did shred - > /this/file/to/be/shredded ... which, of course, undermines shred's purpose. It seems they hadn't your sneaky use case in mind :-) Cheers -- t
[toc] | [prev] | [next] | [standalone]
| From | "Thomas Schmitt" <scdbackup@gmx.net> |
|---|---|
| Date | 2024-02-10 15:00 +0100 |
| Subject | Re: shred bug? |
| Message-ID | <I5W3D-9dMy-7@gated-at.bofh.it> |
| In reply to | #267224 |
Hi, tomas@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 produces a random pattern at all. Have a nice day :) Thomas
[toc] | [prev] | [next] | [standalone]
| From | <tomas@tuxteam.de> |
|---|---|
| Date | 2024-02-10 15:40 +0100 |
| Subject | Re: shred bug? |
| Message-ID | <I5WGm-9eeC-11@gated-at.bofh.it> |
| In reply to | #267227 |
[Multipart message — attachments visible in raw view] — view raw
On Sat, Feb 10, 2024 at 02:58:06PM +0100, Thomas Schmitt wrote: > Hi, > > tomas@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 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? Cheers [1] https://en.wikipedia.org/wiki/Lehmer_random_number_generator -- t
[toc] | [prev] | [next] | [standalone]
| From | Gremlin <scott-andrews@columbus.rr.com> |
|---|---|
| Date | 2024-02-10 14:40 +0100 |
| Subject | Re: shred bug? |
| Message-ID | <I5VKh-9dG6-5@gated-at.bofh.it> |
| In reply to | #267223 |
On 2/10/24 08:32, Thomas Schmitt wrote: > Hi, > > i wrote: >>> shred: -: invalid file type > > tomas@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 "-" is recognized in line 1257 and leads to a call of wipefd() > in line 958. The error messages there look different from above. > So i hop from line 973 to do_wipefd() and find the message in line 845. > fd is supposed to be 1 (= stdout). fstat(2) was successful but now this > condition snaps: > > if ((S_ISCHR (st.st_mode) && isatty (fd)) > || S_ISFIFO (st.st_mode) > || S_ISSOCK (st.st_mode)) > > The problem seems to be in the S_ISFIFO part. > In a little test program fstat() reports about fd==1: > st.st_mode= 010600 , S_ISFIFO(st.st_mode)= 1 > (st_mode shown in octal as in man 2 fstat.) > > It looks like the test expects a pipe(2) file descriptor to be > classified as S_ISCHR and !isatty(). > Without redirection through a pipe, fd 1 has st.st_mode 20620, S_ISCHR, > and isatty()==1. The isatty() result is indeed a good reason, not to > flood stdout by a zillion random bytes. > > > Does anybody have an old GNU/Linux system where a file descriptor from > pipe(2) is classified as character device (S_IFCHR, S_ISCHR) ? > What about dash?
[toc] | [prev] | [next] | [standalone]
| From | "Thomas Schmitt" <scdbackup@gmx.net> |
|---|---|
| Date | 2024-02-10 14:40 +0100 |
| Subject | Re: shred bug? |
| Message-ID | <I5VKh-9dG6-7@gated-at.bofh.it> |
| In reply to | #267223 |
Hi,
i wrote:
> > shred: -: invalid file type
tomas@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 "-" is recognized in line 1257 and leads to a call of wipefd()
in line 958. The error messages there look different from above.
So i hop from line 973 to do_wipefd() and find the message in line 845.
fd is supposed to be 1 (= stdout). fstat(2) was successful but now this
condition snaps:
if ((S_ISCHR (st.st_mode) && isatty (fd))
|| S_ISFIFO (st.st_mode)
|| S_ISSOCK (st.st_mode))
The problem seems to be in the S_ISFIFO part.
In a little test program fstat() reports about fd==1:
st.st_mode= 010600 , S_ISFIFO(st.st_mode)= 1
(st_mode shown in octal as in man 2 fstat.)
It looks like the test expects a pipe(2) file descriptor to be
classified as S_ISCHR and !isatty().
Without redirection through a pipe, fd 1 has st.st_mode 20620, S_ISCHR,
and isatty()==1. The isatty() result is indeed a good reason, not to
flood stdout by a zillion random bytes.
Does anybody have an old GNU/Linux system where a file descriptor from
pipe(2) is classified as character device (S_IFCHR, S_ISCHR) ?
Does anybody have an idea why shred would want to exclude fifos ?
(What ciould shred do with a non-tty character device that cannot be done
with a fifo ?)
Have a nice day :)
Thomas
[toc] | [prev] | [next] | [standalone]
| From | David Christensen <dpchrist@holgerdanske.com> |
|---|---|
| Date | 2024-02-11 01:10 +0100 |
| Subject | Re: shred bug? [was: Unidentified subject!] |
| Message-ID | <I65zX-9jGd-1@gated-at.bofh.it> |
| In reply to | #267223 |
On 2/10/24 04:40, tomas@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".
>
> Hmm. This looks like a genuine bug: the man page mentions it.
>
> Also, /dev/stdout as target runs into the very same problem.
>
> Cheers
Testing:
2024-02-10 16:01:54 dpchrist@laalaa ~
$ cat /etc/debian_version ; uname -a
11.8
Linux laalaa 5.10.0-27-amd64 #1 SMP Debian 5.10.205-2 (2023-12-31)
x86_64 GNU/Linux
2024-02-10 16:02:34 dpchrist@laalaa ~
$ bash --version | head -n 1
GNU bash, version 5.1.4(1)-release (x86_64-pc-linux-gnu)
2024-02-10 16:02:48 dpchrist@laalaa ~
$ shred --version | head -n 1
shred (GNU coreutils) 8.32
2024-02-10 16:03:42 dpchrist@laalaa ~
$ man shred | grep 'If FILE is -'
If FILE is -, shred standard output.
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.
David
[toc] | [prev] | [next] | [standalone]
| From | Greg Wooledge <greg@wooledge.org> |
|---|---|
| Date | 2024-02-11 01:20 +0100 |
| Subject | Re: shred bug? [was: Unidentified subject!] |
| Message-ID | <I65JD-9jJn-1@gated-at.bofh.it> |
| In reply to | #267259 |
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. You wanted to "destroy" (by overwriting with random data) a pipe to wc? What would that even look like? The basic premise of shred is that it determines the size of the file, then writes data over it, rewinds it, and repeats this a few times. A pipe to a process has no size, and can't be rewound. Declaring a pipe to be an "invalid file type" for shredding sounds pretty reasonable to me.
[toc] | [prev] | [next] | [standalone]
| From | David Christensen <dpchrist@holgerdanske.com> |
|---|---|
| Date | 2024-02-11 01:30 +0100 |
| Subject | Re: shred bug? [was: Unidentified subject!] |
| Message-ID | <I65Tj-9jMt-5@gated-at.bofh.it> |
| In reply to | #267260 |
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 to do. You wanted to > "destroy" (by overwriting with random data) a pipe to wc? What > would that even look like? > > The basic premise of shred is that it determines the size of the file, > then writes data over it, rewinds it, and repeats this a few times. > A pipe to a process has no size, and can't be rewound. > > Declaring a pipe to be an "invalid file type" for shredding sounds > pretty reasonable to me. The documentation is confusing: On 2/10/24 16:05, David Christensen wrote: > 2024-02-10 16:03:42 dpchrist@laalaa ~ > $ man shred | grep 'If FILE is -' > If FILE is -, shred standard output. David
[toc] | [prev] | [next] | [standalone]
| From | debian-user@howorth.org.uk |
|---|---|
| Date | 2024-02-11 14:00 +0100 |
| Subject | Re: shred bug? [was: Unidentified subject!] |
| Message-ID | <I6hB7-9qHA-1@gated-at.bofh.it> |
| In reply to | #267262 |
David Christensen <dpchrist@holgerdanske.com> 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 > >> > >> > >> It looks like a shred(1) needs a bug report. > > > > I'm confused what you expected this command to do. You wanted to > > "destroy" (by overwriting with random data) a pipe to wc? What > > would that even look like? > > > > The basic premise of shred is that it determines the size of the > > file, then writes data over it, rewinds it, and repeats this a few > > times. A pipe to a process has no size, and can't be rewound. > > > > Declaring a pipe to be an "invalid file type" for shredding sounds > > pretty reasonable to me. > > > The documentation is confusing: > > On 2/10/24 16:05, David Christensen wrote: > > 2024-02-10 16:03:42 dpchrist@laalaa ~ > > $ man shred | grep 'If FILE is -' > > If FILE is -, shred standard output. Maybe it is unstated but mandatory to use -n 1 as well? And optionally -s N? I expect reading the code would tell. First time I've read the man page properly. Interesting point about COW filesystems such as btrfs :)
[toc] | [prev] | [next] | [standalone]
| From | "Thomas Schmitt" <scdbackup@gmx.net> |
|---|---|
| Date | 2024-02-11 14:30 +0100 |
| Subject | Re: shred bug? |
| Message-ID | <I6i49-9r6l-1@gated-at.bofh.it> |
| In reply to | #267288 |
Hi, debian-user@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, like: shred -n 1 -s 2047999968K -v - | tee /dev/sdm1 | sha256sum > I expect reading the code would tell. My code analysis is in https://lists.debian.org/msgid-search/1162291656137153024@scdbackup.webframe.org tomas@tuxteam.de found bug 155175 from 2002, which explains why. See https://lists.debian.org/msgid-search/ZcdxZya0aYRmPpZ7@tuxteam.de Have a nice day :) Thomas
[toc] | [prev] | [next] | [standalone]
| From | <tomas@tuxteam.de> |
|---|---|
| Date | 2024-02-11 08:10 +0100 |
| Subject | Re: shred bug? [was: Unidentified subject!] |
| Message-ID | <I6c8p-9nHo-7@gated-at.bofh.it> |
| In reply to | #267260 |
[Multipart message — attachments visible in raw view] — view raw
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 > > > > > > It looks like a shred(1) needs a bug report. > > I'm confused what you expected this command to do. You wanted to > "destroy" (by overwriting with random data) a pipe to wc? What > would that even look like? What Thomas was trying to do is to get a cheap, fast random number generator. Shred seems to have such. > The basic premise of shred is that it determines the size of the file, > then writes data over it, rewinds it, and repeats this a few times. > A pipe to a process has no size, and can't be rewound. That's right: stdout is a (potentially) infinite file, so only one pass (-n 1, as Thomas put in the command line) really makes sense. Unless you are into transfinite numbers, that is :-) > Declaring a pipe to be an "invalid file type" for shredding sounds > pretty reasonable to me. This is one of those cases of the toolmaker knowing better than the tool user. One of the things I like UNIX is that this attitude isn't that widespread (it is slowly spreading, alas). I much prefer those tool makers who say "surprise me". Of course, helping people to not shoot themselves in the foot is also a honourable endeavour. So "you are trying to shred a pipe. Use option -f for that (see the manual page" would be fully OK in my book. I don't like opinionated software. It's messy enough as it is when people have opinions :-) Cheers -- t
[toc] | [prev] | [next] | [standalone]
| From | Greg Wooledge <greg@wooledge.org> |
|---|---|
| Date | 2024-02-11 15:40 +0100 |
| Subject | Re: shred bug? [was: Unidentified subject!] |
| Message-ID | <I6j9T-9rHP-9@gated-at.bofh.it> |
| In reply to | #267272 |
On Sun, Feb 11, 2024 at 08:02:12AM +0100, tomas@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 -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. You wanted to > > "destroy" (by overwriting with random data) a pipe to wc? What > > would that even look like? > > 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.
[toc] | [prev] | [next] | [standalone]
| From | <tomas@tuxteam.de> |
|---|---|
| Date | 2024-02-11 15:50 +0100 |
| Subject | Re: shred bug? [was: Unidentified subject!] |
| Message-ID | <I6jjA-9rLR-3@gated-at.bofh.it> |
| In reply to | #267292 |
[Multipart message — attachments visible in raw view] — view raw
On Sun, Feb 11, 2024 at 09:37:31AM -0500, Greg Wooledge wrote: > On Sun, Feb 11, 2024 at 08:02:12AM +0100, tomas@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 there's the discrepancy between doc and behaviour. Cheers -- t
[toc] | [prev] | [next] | [standalone]
| From | Greg Wooledge <greg@wooledge.org> |
|---|---|
| Date | 2024-02-11 16:00 +0100 |
| Subject | Re: shred bug? [was: Unidentified subject!] |
| Message-ID | <I6jtf-9rP5-5@gated-at.bofh.it> |
| In reply to | #267293 |
On Sun, Feb 11, 2024 at 03:45:21PM +0100, tomas@tuxteam.de wrote:
> On Sun, Feb 11, 2024 at 09:37:31AM -0500, Greg Wooledge wrote:
> > On Sun, Feb 11, 2024 at 08:02:12AM +0100, tomas@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 there's the discrepancy between doc and behaviour.
There 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 probing to recover the data.
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".
Once you grasp what the command is *intended* to do (rewind and overwrite
a file repeatedly), it makes absolutely perfect sense that it should
only operate on rewindable file system objects.
If you want it to write a stream of data instead of performing its normal
operation (rewinding and rewriting), that's a new feature.
If you'd prefer the documentation to say explicitly "only regular files
and block devices are allowed", that would be an upstream documentation
*clarification* request.
[toc] | [prev] | [next] | [standalone]
| From | <tomas@tuxteam.de> |
|---|---|
| Date | 2024-02-11 16:00 +0100 |
| Subject | Re: shred bug? [was: Unidentified subject!] |
| Message-ID | <I6jtf-9rP5-11@gated-at.bofh.it> |
| In reply to | #267294 |
[Multipart message — attachments visible in raw view] — view raw
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
[toc] | [prev] | [next] | [standalone]
Page 1 of 5 [1] 2 3 4 5 Next page →
Back to top | Article view | linux.debian.user
csiph-web