91–100 of 178 posts
Somewhat related short story: Earlier this week my friend said that he dd'd away just over 50 bitcoins, back when they were worth ~$3 each. "One of the biggest regrets of my life."
If one of the biggest the biggest lifetime regrets is a $50k financial loss, your friend is doing pretty well.
For those of you that are blissfully unaware of what the JCL DD command looks like, here's a example (with only the DD section of the JCL shown): //SYSPRINT DD SYSOUT=* //SYSLIN DD DSN=&&OBJAPBND, // DISP=(NEW,PASS),SPACE=(TRK,(3,3)), // DCB=(RECFM=FB,LRECL=80,BLKSIZE=3200), // UNIT=&SAMPUNIT //SYSLIB DD DSN=SYS1.MACLIB,DISP=SHR //SYSIN DD DSN=&SAMPLIB(IEWAPBND),DISP=SHR
Ah, I miss elements of the mainframe days.
[0] https://www.ibm.com/support/knowledgecenter/zosbasics/com.ib...
"This is a strange program of obscure provenance that somehow, still manages to survive in the 21st century." -> links to wikipedia page with direct discription of lineage back to 5th ed research unix "That weird bs=4M argument in the dd version isn’t actually doing anything special—all it’s doing is instructing the dd command to use a 4 MB buffer size while copying. But who cares? Why not just let the command figure…
This is a great example of why downvoting submissions should be a thing. Or at least showing the up/down tuple. I would say every upvote represents someone misled and likely to further propagate this nonsense.
Earlier quoted context omitted.
It doesn't need to hunt for the directory entry, just needs to call `fstat()` on the stdin file descriptor.
Unless the input file is a device, and then you need to call: ioctl(STDIN_FILENO, BLKGETSIZE64, &size)
Earlier quoted context omitted.
dd is awful and error-prone for this sort of use. Use noerror, but forget sync? Corrupt output file if there is an error. Use a bigger bs so it's not slow as treacle? A single faulty sector blows away a whole bs of data, and your output image may get unwanted padding appended to the end. Recoverable error? dd's not going to retry. Use ddrescue or FreeBSD's recoverdisk(1). They're faster, they're safer, they're more e…
ddrescue is excellent.
"This is a strange program of obscure provenance that somehow, still manages to survive in the 21st century." -> links to wikipedia page with direct discription of lineage back to 5th ed research unix "That weird bs=4M argument in the dd version isn’t actually doing anything special—all it’s doing is instructing the dd command to use a 4 MB buffer size while copying. But who cares? Why not just let the command figure…
Since coreutils-8.24[1], dd "accepts a new status=progress level to print data transfer statistics on stderr approximately every second."
> Because the command probably doesn't figure out the right size automatically . . . this can mean massive performance differences between invocations
For anyone who's wondering, here are two good threads on determining optimal block size: https://superuser.com/questions/234199/good-block-size-for-d... http://stackoverflow.com/questions/6161823/dd-how-to-calcula...
One thing I'll often use dd for is recovering data from a failing drive. Can head ignore read errors? dd can. As far as I'm concerned, dd is lower-level than most of the other utilities and provides more control over what's happening. The author does have a point that the syntax is strange though.
>One thing I'll often use dd for is recovering data from a failing drive. Funnily enough, I ended up using it to accidentally name the wrong drive in the argument, and lost years of photos, music, video etc. though I suppose I can't blame dd for that :)