Talk:Dd (Unix)/Archive 1

This is an archive of past discussions about Dd (Unix). Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Archive 1

Link to a Windows version?

I think it would be nice if someone adds a link to a Windows version of dd. I am looking for a version which has all the options of the Unix dd. Can anybody help me? —Preceding unsigned comment added by Lefter (talk • contribs) 11:00, 26 March 2008 (UTC)

I added a link to a windows version and examples of use some time ago but some well meaning people removed them as they don't think wikipedia should have examples. Well done on ruining the usefulness of this page guys. —Preceding unsigned comment added by 141.228.106.136 (talk) 09:26, 3 July 2008 (UTC)

files or bytes?

The article says 'dd is a common UNIX program whose primary purpose is the low-level copying and conversion of files' but I think it would be more correct to say that dd copies and converts raw bytes rather than files. NerdyNSK 22:32, 22 September 2007 (UTC)

Agreed. dd operates on a low-level and copies raw data ignoring any filesystem structure, cp is used for the copying of files. Flankk 06:46, 9 October 2007 (UTC)

Actually, "dd if=file of=file2" and "cp file file2" are exactly equivalent. Any program that operates on raw device files directly (the way dd is most often used) will ignore the filesystem structure; this is not dd-specific. (Compare the strace output of dd and cp sometime: the only difference is that cp doesn't have a way to change its buffer size.) When using dd on raw disks or partitions, the files that it "copies and converts" are those device files.

Granted, most people don't normally think in those terms. But that's why the description is worded the way it is in the dd manpage. 99.41.222.169 (talk) 02:23, 23 August 2009 (UTC)

bit-exact versus byte-exact

Can someone explain why dd is byte-exact as opposed to bit-exact? Would bit-exact be more precise? I had the impression dd was a bitwise copy, something google supports; if one searches dd, "bit-exact" one gets more hits than dd, "byte-exact". Nephron 17:59, 21 August 2005 (UTC)

The smallest element dd can access is a single byte. byte-exact implies bit-exact of course. The question is rather what alternate would not be byte-exact? --82.141.60.86 07:32, 13 December 2005 (UTC)

dd does exactly the same as cat or cp on (for example) block device nodes, /dev/zero, /dev/random, etc. -- This article reflects a HUGE misunderstanding in using dd. dd is mainly for CONVERTING streams. For example are the following lines exactly the same (see POSIX for details):

 dd if=/dev/sda3 of=sda3.img
 dd </dev/sda3 >sda3.img
 cat </dev/sda3 >sda3.img
 cp /dev/sda3 sda3.img

139.18.2.46 (talk) 10:16, 20 November 2009 (UTC)

Dd is a bitstream duplicator. That means, even though the program authors have made the minimum block size=1 byte, dd duplicates bits. There are some advantages to using a bitstream, for instance one could stream a single byte, pipe it through a boolean operator, and perform binary arithematic, or bit mask a certain bit array. Normally this is not done manually, but inside a program. [user: AwesomeMachine]

User Jack_Sparrow wrote on freenode.net/ubuntu : "dd is a sledge hammer of a tools, be sure you know where its going before you swing it." shambling 14:48, 10 August 2006 (UTC)

141.228.106.136 It is Byte exact because it can convert little endian/big endian etc.

unexplained details

I find it strange that such old unix command is not well documented in man,some information I cannot find nowhere. What exactly does the output of dd mean? 8+1 records in 8+1 records out what is +1?

It means 8 whole blocks plus one partial block.--Pot (talk) 10:52, 17 March 2010 (UTC)

WHat happens if copied filesize is not a multiply of bs? (block_size)? Will it copy the last partial block or skip it?

Copy partial block.--Pot (talk) 10:52, 17 March 2010 (UTC)

Now word about it in the man. This wiki page is the first place with good explanation of notrunc option I found! I am not qualified to edit the dd page, but maybe some linux guru can do it. Cirocco 15:51, 3 February 2007 (UTC)

Gallows humor

Possibly I'm a very unfunny person. Can someone please explain the gallows humor with the dd command and its syntax, as it is currently written in the article? --Abdull (talk) 21:23, 8 February 2008 (UTC)

It is sometimes jokingly called destroy disk, since one small typo can wipe a disk. Jobarts^-Talk 05:57, 23 February 2008 (UTC)

Top tip; don't copy & paste the wikipedia article to a text file for quick reference, then forget it's in the clipboard and accidentally paste it into a terminal. It can lead to a certain amount of disk thrashing and heart palpitations as the terminal tries to interpret the various DD examples strewn throughout the article. The point of realisation is quite an experience, however, if you're not running a root terminal you'll live. Disk Destroyer indeed :) Tomfin (talk) 13:24, 1 May 2010 (UTC)

Make your drives thrash and get really hot

writing from /dev/urandom to your disk is not a terribly good idea, as it will really work your disk drive very hard, resulting in lots of heat. Not sure wikipedia should be encouraging this usage of dd. —Preceding unsigned comment added by 24.89.158.2 (talk) 04:35, 23 June 2008 (UTC)

dd if=/dev/urandom of= /dev/sda1 bs=4k is no harder on a drive than using if=/dev/zero. When urandon runs out of randomness (entropy), the drive waits until more randomness collects in the urandom device. The write is sequential. [User: AwesomeMachine]

I think those types of examples should be removed from the article, not because the hard disk works hard, but because it just destroys all data!

What else were you expecting? "dd if=/dev/urandom of=/dev/sda" is obviously going to cause data loss. You'd be a fool not to think so. - WorMzy (talk) 01:11, 28 November 2010 (UTC)

Disks over 128 GiB

Anonymous editor (Special:Contributions/64.56.224.79) wrote "Removed 137 gigabyte warning, this was a Windows 9x depdency problem."

Are you saying that 48-bit LBA is only a problem with Windows 9x? That is false. Norton Ghost 2003 doesn't even have support for 48-bit LBA or SATA disks until it is updated (this info is in the Wikipedia article). If this was not clear, this is a direct quote of the Seagate documentation: "Certain disc utilities, such as dd, which depend on low-level disc access may not support 48-bit LBAs until they are updated." Lumenos (talk) 01:35, 8 August 2009 (UTC)

Seagate is wrong (this may or may not be why they took down the PDF). dd does not do any "low-level disc access" itself; it goes through the kernel on its reads from or writes to the raw device files. (This can be verified with strace.) If your kernel has support for LBA48, then dd will also have support for it. Maybe that's what Seagate meant, but it's not what they said -- and it's not specific to dd. 99.41.222.169 (talk) 02:43, 23 August 2009 (UTC)

Anonymous editor went on to say, "Also, source link document is not available."

Look, I didn't make this up. If you can't find a link, the first place to look is in the WayBackMachine at archive.org. This documentation happens to be there (I changed the link to it, in the article). However, Wikipedia contains much information that may not be available online. This is not a reason to delete things.Lumenos (talk) 01:45, 8 August 2009 (UTC)

I have personally had problems using dd/gzip on a large SATA hard disk. It appeared that it could not backup and restore the MBR or a Vista partition. Good chance this is not the reason but it is one possibility. I have searched and searched; for evidence that dd supports 48-bit LBA or SATA, and I can find nothing. I would think that we would hear more about it if others were having this problem but it may be sporadic. I did successfully restore using dd/gzip many times, on the same disk I had the problem on. Backups are often not tested until it is too late. I'm one of the few people who restore my backups right after I make them, so I will have the greatest chance of seeing if they have a non-obvious problem. You can find more details on my problem here. Lumenos (talk) 01:45, 8 August 2009 (UTC)

At the time I wrote that, I had the mistaken idea that the extended partition table was in the MBR. When I restored the MBR with dd, I think I was expecting this to restore the extended partition table as well. My "original research" on this subject should probably be disregarded. Lumenos (talk) 21:03, 7 December 2009 (UTC)

Regardless of our opinions/experiences, Wikipedia's inclusion/exclusion policies state that you must have reliable sources. Please do not remove information from reliable sources. If you have a source that states that dd has support for 48-bit LBA or SATA please add it ALSO and do not delete this info from Seagate; so that we can see both. If you have something from a self-published source (a sorta-expert or something); I wish we could post these things in the Wikipedia but it may be against WP:SPS. You could post it here instead. Lumenos (talk) 01:45, 8 August 2009 (UTC)

Support has been included in the Linux kernel since at least 2.4.23, released November, 2003. (Search that changelog for "LBA48". Note the "ide-disk.c: Limit disk size to 137GB if LBA48 is not available" entry. LBA48 support was present earlier; I have not found when it was added.) 99.41.222.169 (talk) 02:43, 23 August 2009 (UTC)

Thank you for looking this up. I read somewhere that 48-bit LBA was an earlier development than SATA, so support for SATA probably came later. But I suppose all that is necessary for this article is to say that Linux dd depends on the the Linux kernel. I don't know about other *nix. Lumenos (talk) 21:03, 7 December 2009 (UTC)

I plan to invoke WP:IAR to use your comments here as a source for the article. Lumenos (talk) 21:03, 7 December 2009 (UTC)

Recovery-oriented variants of dd

"Also, Linux lacks "raw" disk devices like *BSD has". It is worth noting that while (modern) Linux does not provide raw devices, you can pass the O_DIRECT flag requesting direct access when you are reading/writing a device ( http://www.kernel.org/doc/man-pages/online/pages/man2/open.2.html ). This sidesteps the need for a separate raw device making the paragraph seem incomplete/unnecessary...

144.32.81.88 (talk) 09:08, 4 May 2010 (UTC)

"Note that an attempt to copy the entire disk image using cp may omit the final block if it is an unexpected length; dd will always complete the copy if possible." <- ??? what? is this a bug in some particular kernel? How exactly does a "disk image" have an "unexpected length"? what is a "disk image"? is that different than a "disk"? This sounds like the product of "I don't know why i'm supposed to use dd instead of cp or cat for disk images, but I think you have to" Is there a particular bug that someone can point to? —Preceding unsigned comment added by 74.72.58.219 (talk) 04:52, 7 February 2011 (UTC)

Anti-examples

I would like to delete the section Anti-examples, perhaps just replacing it with a warning. Reasons:

some of the anti-examples are actually legitimate usage and covered in the section Examples, e.g. wiping a disk by writing zeros on it.
it is not necessary to give unkowledgable potential vandals an exact recipe.
anybody knowledgable can use dd to destroy any data anyway.

--Theosch 10:56, 13 November 2007 (UTC)

There will always be poor vandals among us. :-) It is probably more likely that a legitimate system admin would mistype a dd command, causing damage, than for a vandal to gain proper access and use the example to destroy data. --Unixguy (talk) 19:06, 27 November 2007 (UTC)

Oh wow. I know it's been 4 years, but welcome to the internet! — Preceding unsigned comment added by 91.44.13.240 (talk) 01:38, 13 September 2011 (UTC)

Should dd be capitalized in the first word?

Should dd be capitalized in the first word of the article? Capitalize the first letter of the first sentence? "Dd is...". Well, dd is a word, as well as a terminal command. — Cpiral Cpiral 17:38, 6 September 2011 (UTC)

I think it is important to capitalise the first letter of every sentence, otherwise it looks awkward. However I believe dd as a Unix command should probably be written using lowercase letters. I suggest rewording such sentences, maybe like “The dd command is a program.” (While we’re on the subject of style, I also dislike using monospace and other typeface changes amongst a paragraph of text, when bold, italics or quotation marks are good alternatives.)

The MOS seems to say much less than expected about starting a sentence with a capital letter. MOS (dates and numbers)#Numbers as figures or words says avoid starting sentences with a numeral but for a different reason; MOS (trademarks)#Trademarks that begin with a lowercase letter similarly says avoid starting sentences with trademarks that must begin with lowercase. Vadmium (talk) 02:48, 7 September 2011 (UTC).

Accordingly

Unix command dd is a common, system utility for low-level copying and conversion of raw data. The dd application will "convert and copy a file"[1] according to the referenced manual page for Version 7 Unix.

— Cpiral Cpiral 11:54, 7 September 2011 (UTC)

I've undone this (along with some undiscussed syntax changes by an anon editor). So long as the convention is made clear beforehand (as it is, with the use of the{{lowercase}} hatnote) there is nothing wrong with starting a sentence with lowercase if it begins with a proper name, and the resultant changes were very awkward. Chris Cunningham (user:thumperward) - talk 13:02, 12 September 2011 (UTC)

Starting a sentence without using a capital letter looks awkward to me, so I disagree that there is nothing wrong with it. especially after a full stop in the middle of a paragraph. Hopefully I can fix it so the wording isn’t too awkward either. Vadmium (talk) 08:34, 13 September 2011 (UTC).

I've posted some research on this topic at Wikipedia_talk:WikiProject_Computing#Unix_commands. It's a list, cut and paste from other Unix commands articles, showing how they start themselves out. (List of Unix utilities is convenient.) — Cpiral Cpiral 06:04, 14 September 2011 (UTC)

Resored deleted section "Data Recovery"

There seemed to be some material relevant to dd concerning it's data recovery behavior that was deleted in the removed section. There were also some references removed after that. I have reverted the changes in their entirety for now for these and other issues I might bring up concerning the removed content's benefit to the article. This section needs does need editing, but please discuss if removing large amounts of material. — Cpiral Cpiral 23:27, 20 September 2011 (UTC)

The "references" which were removed were citations to a Wikipedia talk page. Under no circumstances are such things ever considered to be valid in articles. I'm done attempting to work around the obstruction here: future changes will be proposed here, taken to WP:3O and then to RfC if that fails to find a resolution, starting with the removal of those references and later moving onto the deletion of the "data recovery" junk and all the manual stuff. Chris Cunningham (user:thumperward) - talk 10:16, 21 September 2011 (UTC)

Recovery-oriented variants of dd: neutrality

This paragraph needs to be worded in a more neutral tone. I also doubt that Antonio Diaz Diaz is notable enough to be quoted so prominently, as a developer of ddrescue he surely lacks impartiality anyway. — Preceding unsigned comment added by 91.44.51.205 (talk) 01:33, 13 September 2011 (UTC)

I've removed the entire section. This isn't supposed to be advertising space for derivatives. Chris Cunningham (user:thumperward) - talk 09:12, 13 September 2011 (UTC)

Exactly my point, thank you. — Preceding unsigned comment added by 91.44.45.54 (talk) 17:42, 13 September 2011 (UTC)

Thank you for volunteering your general opinion, and the improvements you are trying to make. What is your point, exactly? i.e. precisely what is the POV? The authority of an educated computer scientist concerning "very efficient" or "not very efficient" cannot be a POV. Efficiency categorizations have to do with the mathematical properties of summations, and the things being summed up are execution times of statements, and the way they grow over larger and larger data sets. A hard drive is a large data set! If some sweat named Diaz volunteers to write the computing world a procedure that was the result of a study concerning the precise attack of the inefficiency that is (beyond doubt) inherent in a procedure the size of dd, and if another mature developer appreciates so much to wrap another sophisticated shell script around it then there, we have sufficient evidence. The phrase "very inefficient" was meant to be objective, I'm sure.

But what is more important is not a reference to the published code (of dd and the honed dd for data recovery on a HD), and the comparison of their timing functions analysis (which as I said, cannot have a POV) as you seem to need so urgently. That publication may never, alas, see the light of day. What is more important is the impropriety in the way this section was removed. (I have restored it, thank you.) The POV tag was eight hours old, for Information's sake! Furthermore, the removal of information from Wikipedia is not to be taken lightly. The programmers evolving dd's realm are volunteers. The persons who wrote the removed sections are volunteers, and the information is, in my volunteered opinion, at this point in time, relevant.

I am now open to logical and precise arguments concerning the removal of the "offensive" quote, but hardly the section's informative content. If the entire section is to be removed, it cannot for POV; it could be removed for the article size being too big, or for the material being irrelevant. — Cpiral Cpiral 06:58, 14 September 2011 (UTC)

The material was removed because it was irrelevant. This is not an article about derivatives which happen to be based on dd: every Unix utility has thousands of programs built on it, and they don't all get advertised in the parent articles. The "educated computer scientist" may well have an educated opinion on how these utilities compare to one another, but it is irrelevant to dd itself. If you want to do something useful with this content try adding it to a new article titled Recovery-oriented variants of dd or the like. Chris Cunningham (user:thumperward) - talk 08:39, 14 September 2011 (UTC)

We should leave it in for now because

It's importance as a History section. Evolutionary/Historical proceedings (See Recovery-oriented variants section.) are not just the trivia describing relative conveniences, like a GUI or a minor feature extension, they are absolutely necessary, to inform how the prevention of further damages (See the intro. and the Recovery-oriented variants sections.) won out yet again. Such sections as these inform of Progress in overcoming gross inefficiencies inherent in dd developers' limitations.
It is a small, start class article. It was removed for the wrong reasons.
The variants are not notable and would not survive.
Dd is unique in style, ubiquity, (See Usage.) and fundamental action. (It's now in the Linux kernel, etc.) The burden here is to prove dd is not unique (E.g. something like "tar is used in pax, yet pax is not in the tar article."), i.e. another Unix command has the same situation and yet they have debated and removed similar material for irrelevance.

This being said, "Happy editing!" on this rough and tumble-weeding article. It needs it. — Cpiral Cpiral 19:18, 14 September 2011 (UTC)

That the variants are not notable is precisely why the content does not belong here. Our job as editors is not to find a place to put any random fact found on the Internet: editorial discretion strongly suggests that adding an entire page of content which is at best tenuously related to the subject to a short article which is already burdened with unencyclopedic content is not in its best interests. I find your argument about "history" unconvincing: it would certainly make sense to add a little to the article detailing how people have built on dd and made use of its novelties for complicated tasks, but that is quite different from adding a section which reads like a software guide and consists primarily of usage guidelines. Given that the entire section is sourced to nothing other than the vendors of the software in question, it is not obvious that it would even be useful as a starting point for the proposed section. Chris Cunningham (user:thumperward) - talk 21:31, 14 September 2011 (UTC)

I agree in full. It is little more than cruft. What distinguishes these tools from all the other recovery tools out there? It seems to me that it amounts to little more than the fact they feature "dd" in the name. A couple of lines would not be out of place but an entire section complete with examples on niche tools that in reality have little to do with the subject of the article is disproportionate. A good article should be comprehensive, certainly, but it also needs to be focused: going off on a tangent and covering unrelated tools does not serve the reader. Personally I think the article as a whole is suffering from this: we could probably greatly improve it by throwing half of it away, but since it's this section under discussion we may as well start with that. Crispmuncher (talk) 01:10, 15 September 2011 (UTC).

If anything of this section is going to be salvaged, perhaps it could be integrated into a section about disk copying applications, or error handling and whatever the noerror option does. Vadmium (talk) 03:23, 15 September 2011 (UTC).

The contradictory statements and actions involved here are too complex for me to manage personally and immediately, logically, precisely, and reasonably. So I offer a (long) general opinion showing how right we all are about this section's contents as regards the entire article and especially about *nix-command articles in general. Mostly, I am advocating for keeping as much removed information on Wikipedia by moving it rather than deleting. In the case of *nix commands, there are two kinds of info: internal and operational. Please see the article Tar_(file_format) to appreciate this. The tar article has both, and is in the category "tar (file format)" with a redirect from "tar (Unix)", but the article strikes a nice balance between internals (developer stuff) and operations (user command line examples.)

Article style The two general styles for *nix command article are 1) functionalist/behaviorist/operations-oriented (like section 1, user-level, Unix command documentation in the manpages), and/or 2)developmental/historical/internal-analysis-oriented (like OS-related articles), or both. By style I mean content-style. They have a different style of presentation and a different audience.

Compare the styles of this article with the styles of OS-related or programming-language-related articles. Operations style content hides the implementation details. From the purely operations style article perspective, dd would have examples, but not mention "efficiency". A purely "internals" style content is like the Plan 9 from Bell Labs article, includes "Design concepts ... unified model ... files and names ... directories ... /proc ... /net ...networking...". It says little about the user operations of Plan 9. A purely "internals" style dd article would document the libraries of dd, the design concepts, the algorithms, the modules and filenames, and also how it fits into ddrescue and what the efficiency trade-offs are. Now, like tar, we have both.

It is not clear yet whether the wiki will evolve two or more articles for each *nix command, dd (user) and dd (developer), because although *nix commands might seem an unusual category of articulation as concerns an encyclopedia, they are notable enough as a subject, and there is ample room to expand expand the subject into two articles per the Wikipedia's policies concerning the creation of summary articles when the subject becomes to large in size. We even have Unix functions like getchar()! ()! Should dd have all its information including internals? I'd say yes, and eventually, it may seed a new article—dd (internals). (WP:Notability concerns article subjects not article content. So I would compare a Wikipedia page's contents to the manpages. One command description may exist in two content styles, the technical/internal/development content style with source code and system and library information detailing design considerations, versions, etc, and one for basic users. Most *nix commands only exist in section 1 of the manpages, but some exist in more than one section. Although the user-operations approach will be the dominant style on a wiki for the near future, there is hope that information concerning *nix commands will evolve to include system, library, and programmer-developement information. This is true because everything about a notable *nix command, all its encyclopedic content is notable. The ddrescue section will eventually belong to a developers version of dd, just as parts of the tar article might become developer versions of the tar article.

Article class and size The recommended read-time length of 15 min. should be kept under parts of the considerations for judging content removal if the content is deemed relevant. "What serves" or will serve the audience is a targeted 15 min. read, no matter how widely focused (or put in another way "unfocused") the content. Starter class article's should achieve a 15 min. read-level of information before editors start removing relevant content. In dd's case here, there are extreme views about deleting "all variants" and/or "all examples". (See the "examples" discussion above.) When good effort examples and variants are are added, and when this then makes the article too long, then hopefully the good effort will not be removed (deleted) or moved until it has a sustainable place to land, like a notable stub. The advantage of this size-based approach is that the discipline is moved to the future reality, and that way information is not removed "now" from Wikipedia based on some vision of a "perfectly concentrated and relevant content" future state of the article, which is just living in a group's or a person's vision rather than the pages actual reality.

For these reasons then I maintain we keep the ddrescue section, but edit it for lucidity, as usual. I think ddrescue is related to dd, that it uses dd, that it is there because of dd, etc. I think so not by familiarity (although I have the source code for these two, and could investigate), but by Diaz' comment—the quote by Diaz uses dd—and by the real possibility that five steps of the six-step ddrescue algorithm use dd for read/write access to the disk and by another discussion on this talk page.

— Cpiral Cpiral 01:42, 17 September 2011 (UTC)

I have to say I fail to see the relevance of most of this. We cannot meaningfully discuss the internals of dd here: like most Unix tools it has been implemented several times (AT&T, BSD and GNU for a start). We can talk about the internals of Plan 9 because it is a single something concrete, and as a research operating system its internals are in a sense its very reason for existence, so covering them is relevant and possible. What is the encyclopedic value of discussing the internals of dd? Which internals do we discuss?

Similarly, the tar file format is an inappropriate comparison. A file format is an externally visible entity. The format needs to be clearly documented for the purposes of interoperability. That isn't the case for the internal buffers, pointers, counters and whatever else dd may use purely internally and only during its actual execution.

In any case, much of this discussion appears to dramatically overestimate its complexity: the core "algorithm" is trivial. Even K&R gives a simple dd-style tool as one of its examples and doesn't devote more than a few pages to it. That is relevant here - if we say these tools are derived from dd we are making an assertion based on 10 or 20 lines of C. I don't see that as a legitimate basis for inclusion. That leaves us with the name only which I've already covered above. Is that really reason to cover tools that differ virtually in their entirety, that are dependant on sources that do not meet normal standards of reliability, and conveniently ignore the presence of e.g. dd's "noerror" directive in order to present themselves as something more revolutionary than they really are? Crispmuncher (talk) 02:54, 18 September 2011 (UTC).

But...but it has been asserted by Diaz that dd and ddrescue are related. The burden here might be to prove Diaz wrong. But even so, they are operationally related. So the burden had to move to the internals, and to the plaintiff, that this is grounds, nay, argument for grounds, for removal. But even such a feat as a victorious software-patent-lawyer might achieve, this is shallow ground for accusing a section of a crime whose sentence is death, because algorithmically they are related. Externally, and concretely they are related. Obviously, operationally they are related. If they are related section ddrescue is relevent to article dd. Basically, section ddrescue (We might as well call it that.) stays in article dd until a simple discussion "delete or include" can be completed. There was mention of editing it instead, of keeping it. I noticed the complexity involved and tried (above) to make the dd article debate about deleting a section more simple by deferring to operational aspects of *nix command articles in general. WP moves or deletions, as any action of life, requires particular reasons, certain things. There have been some good points for "dis-inclusion" countered by "don't remove info from WP". Please, what are remaining, particular reasons for deleting the section again? (Discussion page guidelines to the rescue!) — Cpiral Cpiral 17:28, 18 September 2011 (UTC)

An alternative solution which doesn't involve any quasi-legal metaphors or pseudo-philosophical rambling about the lifecycle of articles would be for the section to be removed until you can, succinctly and in plain language, explain how it relates to the subject and why it should take up roughly a quarter of the article's total length (half, stripping the manual content from the preceding section) and get consensus for its reinclusion. That's the solution I'll be pursuing on my next pass, as the onus is and always has been on editors adding disputed content to articles than on removing it and you've yet to convince anyone of the section's overall value to the article. Chris Cunningham (user:thumperward) - talk 13:04, 19 September 2011 (UTC)

Diaz is not a reliable source since he lacks the necessary independence. We do not need to rebut his comments: we can ignore him. This is not simply using a technicality in support of a position: as noted above he chooses to elide over options present in dd that directly address the issues he attributes to the tool. That kind of bias is precisely why our rules on sourcing are the way they are.

I want to be sure, this time, what you refer to. Is it where he said "not very efficient?". (I reworded that information in the article.) If by "not simply using a technicality" and "options in dd" you are refering to conv=noerror, then I can start to agree. — Cpiral Cpiral 17:06, 22 September 2011 (UTC)

As for the reasons for deletion, I believe it has been made succinctly. Frankly, it is not the pro-deletion camp that has brought in a vast amount of irrelevances that almost resemble the Chewbacca defense. Ddrescue is not the subject of the article. What singles out ddrescue over any other recovery tool? How does drifting off topic serve our audience? It doesn't, therefore it should go. Crispmuncher (talk) 00:02, 22 September 2011 (UTC).

I believe the changes I recently made show how ddrescue is mentioned for the purposes of teaching exactly what dd is, and how dd should be used. At this juncture of the development of this start class article, I use ddrescue as an excuse to talk about aspects of dd. What do you think about something like this for the section in question:

The noerror option to dd, plus the smallest possible block size (lowest possible level of data recovery) for dd, will recover or rescue data, but this entails extensive and intensive I/O. Each run of dd will use a single block size for input and output. Now in order to quickly rescue an ailing drive, dd's output block size should span a large cluster of sectors. However, in order for error-free output, a linear, byte by byte read of the input, requires a small "ibs" or "bs". An input error would otherwise default to doom 512 bytes of output. For an ailing drive with errors the block size needs to vary in such a way that it is large at times and small at other times. Although dd has no algorithm as regards data recovery, a single run of a data recovery tool will make several passes, each intelligently targeting "skip", count", "bs", and/or "direct" options concerning the input.

Now if you want to know what singles out ddrescue, see "Damaged hard disk" in the references section. While there (scroll past Knoppix stuff) note how much a person can learn about dd's bs and noerror options incidentally by reading about how ddrescue and dd_rescue work, when there are examples of what dd would have to do to emulate those functions. — Cpiral Cpiral 17:06, 22 September 2011 (UTC)

The pop and pushed stack of excuses for the hasty deletion (See how to discuss on talk pages.) include irrelevance, notability, neutrality, and relevance. Now it's size. Someone please edit the section down to size. Don't worry, It won't get deleted in 8 hrs? — Cpiral Cpiral 00:32, 20 September 2011 (UTC)

examples not needed...Wikipedia is not a...

Wikipedia is not a manual, guidebook, or textbook. Policy explicitly states that "a Wikipedia article should not read like a how-to style manual of instructions, advice (legal, medical, or otherwise) or suggestions, or contain "how-to"s.". The "usage", "examples" and "anti-examples" of this article are exactly that and should be deleted. I see no reason for keeping these sections in an encyclopedia. --Pak21 (talk) 15:45, 23 November 2007 (UTC)

I was bold and removed both example sections. The usage section remains. --Unixguy (talk) 17:21, 26 November 2007 (UTC)

I can tell this isn't going to be easily resolved. While an example or two is appropriate for any encyclopedia, it's overboard to have 18 examples, followed by 7 more "anti-examples" DD is a useful tool, and may be used or mis-used in many ways. I put in a couple examples in the main text. --Unixguy (talk) 18:51, 27 November 2007 (UTC)

What I think would be a good compromise if we could find some verifiable sources stating a couple of examples. I had a quick look yesterday, but couldn't find anything really good. On another note, the "Usage" section seems to be a direct copy of the GNU coreutils man page for dd, which is licensed under the GPL, not the GFDL and hence cannot be included here in the essentially unchanged form it is. I'll remove it. Cheers --Pak21 (talk) 09:12, 28 November 2007 (UTC)

I agree that the examples section was excessive and the anti-examples section superfluous. However the article now perhaps does not do enough justice to the unique possibilities of dd and I would recommend putting some of the examples back. Wikipedia_Dd was actually quite a good resource, as the dd man page is rather minimal and has no good examples. --Theosch (talk) 18:15, 10 December 2007 (UTC)

The examples are not procedures. They are one liners. Each line is a kind of sentence. Each example uses a different parameter or "word". A how-two is many lines and paragraphs, but these innocent dd examples are an example of lucidity. Yes, lucidity has an organic change principal that basically says use the word, dd in this case, over and over and over again, in all it's contexts. That way you convey the real meaning without really having to explicitly describe it. You show what it does and don't say what it does. — Cpiral Cpiral 21:15, 9 September 2011 (UTC)

Posix/*nix commands examples are unlikely to fall under Wikipedia how-to template-warnings. Why, Linux How-to documentation does not include *nix commands. *Nix commands are not procedures. — Cpiral Cpiral 08:27, 15 September 2011 (UTC)

The How-to tag will soon be removed for the above reasons. — Cpiral Cpiral 18:38, 14 September 2011 (UTC)

How-to or not, I think the section needs tidying up. Seems to me there are actually a few distinct categories of examples. Maybe they could be swallowed into descriptions of different common applications of dd as illustrations, which might avoid of the brainstormy tutorial feel of it. (Just a thought.)

Disk copying. There are lots of these. Maybe too many examples can spoil the broth? Do we really need examples for entire hard disk devices and single partitions?
Constrained copying. Using the seek, skip and count parameters to read and write segments of regular and special files and to create sparse files, although it is not always practical.
Conversion. How useful or not is the "convert a file" functionality? There’s actually an example of uppercase conversion hidden towards the bottom.
Pipelines. In some examples dd was effectively a no-op like cat. The pipeline application or the other tools used are often more interesting than the dd usage.

In each example that is included, I think their workings should be explained. Why do they choose a particular bs value; what does noerror do more specifically? (Make up dummy or sparse data if reading fails and ignore write failures I guess but I haven’t looked it up.) Why 2048-byte blocks for a CD but 1 MiB or otherwise for a hard disk? Sometimes the block size isn’t even specified. Vadmium (talk) 03:16, 15 September 2011 (UTC).

Yes. It is a wakeful good thought to categorize the functionality as you are doing, and to use an example for each of the many aspects of each of the functions of a *nix command. (As for the "broth" see lucidity axioms about "organic change principle".) To my mind a wiki is all about sections that are categories/aspects of the subject. A fully articulated description of a *nix commands' brilliant compendium of logically bound functions is hard-earned, reverse engineered, natural language sections, sans gurus (obviously). Manpages and info documents lack examples, and are too terse for our target audience. Therefore on the wiki, an example for each aspect of each function of a command is appropriate. Our description of such gems attempts to eventually reflect fully, all the particular facets of life's computing problems the particular command was born for. Perhaps a wiki is the best way to (eventually) get the full, lucid description that the program's many authors could have hoped for beyond the most awesome man pages. — Cpiral Cpiral 08:27, 15 September 2011 (UTC)

OK. My best vision of the proposed sections is: they introduced themselves, provide four or five examples in a table, and conclude themselves. The intros describe pre- and post-conditions, and the conclusions provide a general description of outputs. Note: One or two examples will not suffice. The plethora of operations—dd has 22 parameters and 33 flags— of a *nix command prove the possibility of exemplifying a large number of unique operation. Some combination of parameters (and/or) pipes may be entirely special, "discovered" behaviors. We are not even limited by the size of the article because we can split off sections to create a grandaddy dd page WP:Summary style, linking to dd copy operations and dd convert operations. Also any references to manpages or info-documents would be good in the proposed sections. — Cpiral Cpiral 01:16, 18 September 2011 (UTC)

Oh, and don't forget the 25 deleted examples from the 26 November 2007, manpage version of dd. We might want to fit most of them into this 2011 version vision. — Cpiral Cpiral 02:04, 18 September 2011 (UTC)

Absolutely not. The section needs completely reworked to include only the most pertinent and illustrative examples along with secondary sources which explain why they are so illustrative. it does not need to be some flowery reinterpretation of the man page sourced only to the personal musings of the editor responsible, which is how the vast majority of examples sections on Unix utilities sadly find themselves at the moment. Chris Cunningham (user:thumperward) - talk 13:09, 19 September 2011 (UTC)

Dear dad, Thanks. No flowers. We'll get right to work toward effort that promises to be un-wasted. (Unfortunately, I'll be out of time.) Happy editing effort can safely commence on Vandium's four sections. For example:

== disk copy ==

of could destroy data depending on semantics.
bs depends on the block size.
count multiples of bs are the disk's size

Read the man page to ensure these examples are safe for your system.
`$ dd if=/dev/cdrom of=image.iso bs=2k`	Copy a CD to an ISO image file named image.iso
`$ dd if=/dev/fd0 of=floppy.img`	-
`$ dd if=floppy.img of=/dev/fd0 bs=18k`	-
`$ dd if=/dev/random of=reallylargefile count=2M`	To create a file of the size 1 GB with the name reallylargefile, filled with random data

A typical response for an 8 block disk would be

9+1 records in
9+1 records out
5065 bytes (5.1 kB) copied, 0.00147114 s, 3.4 MB/s

==End Cpiral's example section==

(The royal) We agree, on the proposed restore of all illustriously removed impertinent examples, and on a new group of sections. We do this in place, on the talk page. After this is done, however, I disagree about the additional proposed task of "sourcing". Here's why. We should decide what goes into the article, and then we should put it there without {{citeweb}} or {{citebook}} prerequisites. Not only is *nix-cli article style unique, but We're unlike any other a venue on Wikipedia concerning copies of quotations. Others articles cite complex opinion; but ours interprets textual words between code tags to represent a simple boolean binary logic whose falsehood is vandalism, and thus reverted. Primarily, we're it. This would be very different in, say, an article on the Tea Party, where a blog might be an invalid source. Therefore to "source/cite/refer" a CLI example is unto ourselves—47 watchers now preventing misinformation here, and 30 000 page hits/month preventing vandalism when it is in the article later. This is crowd-sourcing. It is recommended (see MOS:CLI) that, besides ourselves, is "a copy of an output". To me this is a secondary source— it is unbiased, authoritative, and always runs the same way. It is the (hypothetically ubiquitously similar) computer OS, none of which are "invalid for dd" because, like all computer programs, they all run dd the same way every time, given the same input.

On this last point: forgive my analogy, but this is like software development in its specification stage. Show the command prompt as input to the brain, then dd's formal statement/expression, then show the output of dd. This develops the readers brain "software". In this analogy the raw data input is '$', followed by a functional pose of dd. Given the output, the three parts become a unit of "the specification" for the brain to inwardly manifest per Wikipedia's explanation of dd. 'Nuff said.

My whole problem is how easy it is to criticize, rather than to simply show a better example. — Cpiral Cpiral 00:10, 20 September 2011 (UTC)

Firstly, all MOS:CLI does is explain how to format command line examples: it does not discuss their usage, and it certainly does not encourage the sort of examplespam that currently plagues articles. Secondly, your proposed examples section doesn't actually address the problem: this is not a manual, and we are not here to teach people how to use programs any more than our articles on aeroplanes are supposed to teach people how to fly. Chris Cunningham (user:thumperward) - talk 09:32, 20 September 2011 (UTC)

I already addressed "this is not a manual". Please address that discussion instead of starting it over. Maybe this will address the problem you point out:

"Wikipedia articles are intended to be narratives, not guides or places for stockpiling information, 
 as explained at What Wikipedia is not (shortcut: WP:NOT)."

It is possible to make the examples into a narrative about dd. Like any poor writing, the current list of examples does look poor, but start class articles look this way for a while. Thank you for your patience thus far, thumperward. — Cpiral Cpiral 00:26, 23 September 2011 (UTC)

The Great Zero Challenge

From this site, quoting:
"Q. What is this?
A. A challenge to confirm whether or not a professional, established data recovery firm can recover data from a hard drive that has been overwritten with zeros once. We used the 32 year-old Unix dd command using /dev/zero as input to overwrite the drive. Three data recover companies were contacted. All three are listed on this page. Two companies declined to review the drive immediately upon hearing the phrase 'dd', the third declined to review the drive after we spoke to second level phone support and they asked if the dd command had actually completed (good question)." —Preceding unsigned comment added by 82.243.0.45 (talk) 11:22, 7 September 2008 (UTC)

Now added a reference for this. --Pot (talk) 14:22, 7 March 2012 (UTC)

Best on unmounted devices ??

I came here looking for some advice as to whether the devices need to be mounted first .. and if they are already mounted, whether they should be unmounted first — perhaps that information could be added — cheers, Robbiemorrison (talk) 18:42, 12 May 2012 (UTC)

It probably depends what you are trying to do, and what the operating system supports. But I suggest you look for or add such information to articles like Mount (computing) and Device file. I’d expect reading and writing a mounted device (whether with dd or another method) might bypass caching done by a file system driver. Vadmium (talk, contribs) 07:36, 13 May 2012 (UTC).

cancel or quit dd ?

missing info .. typed "dd" at the prompt by mistake.. did not know what it was went on wiki and was unable to find a way to quit dd with out doing any thing tried [CTRL]+[C] it quited with

"0+3 records in 0+0 records out"

have no idea what it did.. If some one knows the meanig and a proper way to quit dd i this this would be usefull.

SirDabour —The preceding unsigned comment was added by 212.98.41.187 (talk) 17:31, 31 March 2007 (UTC).

I am no expert, but I suspect it was trying to copy bytes from std-in to std-out. And in this case those would seem to be your console. So, it seems like you did the right thing to quit, and it should not have changed your filesystem in any way. Maybe CTRL-Z would be another way to exit? -69.87.200.37 19:00, 12 October 2007 (UTC)

If you ever find yourself stuck inside a unix-like command, such as dd at a command terminal, try <ctrl-d> or <ctrl-z>. Proceed gently up the kill signals. (<ctrl-c> is like kill level nine, rather harsh.) All the I/O is just as it is with the file I/O, even if it's not a file, even if it is the terminal/keyboard you are typing on. When EOF (end of) is read, the application is done and it exits. But EOF is determined by the software. For example, Unix tools ported to Windows OS vary as to the EOF. Cygwin uses <ctrl-d> (the usual EOF); in MKS Toolkit it's <ctrl-z> (the Windows EOF). (See also ps. See also jobs, exec, and the shell-dependent concepts of suspend and forground.)

By the way, we are out of line by concerning ourselves on the talk page of Wikipedia with such matters. Happy editing! — Cpiral Cpiral 19:55, 7 September 2011 (UTC)

Actually, ^C is generally a SIGINT, a fairly "soft" kill signal, albeit by convention a bit more forceful than a SIGTERM. kill -9 equates to a SIGKILL which is substantially different since the program isn't given an opportunity to handle the signal and close down gracefully, it's simply killed stone dead. If you sent a SIGKILL you wouldn't get the "results" output since dd wouldn't be running to output it. Crispmuncher (talk) 21:53, 4 July 2012 (UTC)

This is silly [having so many examples]

We don't need so many examples. This page shouldn't be a man page or a page of examples. Come on. —Preceding unsigned comment added by 129.78.64.102 (talk • contribs)

I agree. I think there's a template for this kind of thing. --Ysangkok 19:06, 27 June 2007 (UTC)

I disagree. We surely need to have lots of examples. This is one of the reasons why someone searching from Google would prefer to visit Wikipedia rather than many of the other sites having information on dd. NerdyNSK 22:28, 22 September 2007 (UTC)

I disagree as well. The reason most people are going to google for this is they want to know how to use it. Wikipedia is one of the usual go-to sources when looking to learn something, and not having this information would cause the user to regret visiting Wikipedia.96.38.249.66 (talk) 20:24, 13 September 2012 (UTC)

Please keep the examples (and anti-examples). -69.87.200.37 18:56, 12 October 2007 (UTC)

This discussion continued in the Anti-examples section below. --Unixguy (talk) 18:47, 27 November 2007 (UTC)

Recovery of overwritten data

I've just restored some already sourced text for the second time in as many day. The first time around I referred to [1] as an additional reference, which was again delted as supposedly silent on the issue. On the contrary it goes into considerable depth on the issue: for example, p7-8 discuss the difference between clearing (overwriting - the document makes clear simple filesystem level deletion does not count) and purging (ensuring data is irrecoverable even after it has been overwritten) A footnote on p12 discusses this at length noting the implausibilty of recovering overwritten data from high capacity magnetic hard drives specifically, but makes clear this is a specific exception not a general rule. Crispmuncher (talk)

To be clear, what is being questioned here is whether anyone in the history of time has proven that overwriting with random data is more effective at preventing recovery of the original data than overwriting simply with zeros.
Before reverting your revert I searched the document you have referenced for the strings "random", "zero", "recover", "laboratory"; not only did I find no information to suggest that overwriting with random data is more effective than overwriting with zeros, but I found not even a single claim to that effect.
As if that were not enough, I have now read every single word of each page you have explicitly mentioned (and the appendix information parts of those pages referred to), and there is still not even a claim, nevermind a conclusion backed up by anything resembling scientific measurement. This document simply does not pertain to the issue.
I'll check your contributions to ensure you have been given ample time to respond before reverting again. ¦ Reisio (talk) 01:58, 12 May 2012 (UTC)

Sorry, I hadn't read this earlier. I suggest you re-read the existing document: it specifically states that over-writing with NULLs which is what you suggested is not sufficient: it must be over-written with non-NULL data. A random source is a suitable source, /dev/null or /dev/zero isn't. I do recall an MIL standard that required over-writes but don't seem to be able to find it right now, but this paper makes the point explicit: [2] Crispmuncher (talk)

Read the epilogue. ¦ Reisio (talk) 01:43, 9 October 2012 (UTC)

DD means din dayal or deepak deewana or deepak gupta

DD means din dayal or deepak deewana or deepak gupta from kautilya collage

Actually it's short for "Copy and Compare" (exactly what it does), but cc was already taken and so they called it dd. —Preceding unsigned comment added by 85.177.137.52 (talk) 11:34, 29 January 2009 (UTC)

Close. Taken from the man page for dd:

NAME
  dd - convert and copy a file

dd is short for "convert and copy", except cc (C compiler) already existed, so it was "incremented" to dd. That being said, the source I heard this from said he learned that from one of the original authors, so take that as you will. 15.243.169.69 (talk) 22:58, 3 February 2009 (UTC)

I learned to know dd way back in my early Unix days as a tool "to dump disk data to a file" and vice versa and I think, that suggests the most convincing explanation of its name dd = disk dump.--BerlinSight (talk) 18:41, 22 December 2012 (UTC)

Custom Signature not Possible?

Am I right to assume then that it is not possible to wipe a drive with a custom hex or ascii signature? There's only Urandom and Zero/Null? I'd like to dd/if=(somehow customized string like 55aa) of=/dev/sda 50.47.102.4 (talk) 10:50, 3 February 2013 (UTC)

dcfldd allows to use a custom pattern, I recently added it to wikipedia, and is much more powerful than dd(dd is great and I still use it of course)

Swestlake (talk) 18:53, 4 April 2013 (UTC)

Proposal for changes

(please see any updated proposals towards down of the page)

prior

In computing, “dd” is a common program for Unix and Unix-like operating systems whose manpage describes it's purpose as to "convert and copy a file."^[1] dd's instructions are meant to be read by storage experts where the terminology of file is not loosely interpreted. On Unix-like systems, hard disks (such as /dev/sda and /dev/sdb) and other device files (such as /dev/zero and /dev/random) appear in the filesystem like an ordinary file but are actually special. The program dd reads and writes to these special device files on a byte-per-byte basis. As a result, dd can be used for tasks such as backing up the boot sector of a hard drive, and obtaining fixed amount of random data. dd can perform byte order swapping while copying bytes from device files, as well as from binary data files. dd can also convert text encodings of ASCII and EBCDIC formats, whereby device or binary files are not practically used for this mode of operation.^[2]

Swestlake (talk) 18:23, 4 April 2013 (UTC)

A few points:

I'm not sure what "dd's instructions are meant to be read by storage experts where the terminology of file is not loosely interpreted" means. Which means it's not going to be clear to other users, either, and the lead needs to be as clear as possible.
I don't think there's anything to gain from naming hard disk paths; listing examples of special devices is useful since it may not be obvious what they are, but I don't think naming paths to hard disks makes the lead any clearer.
I don't like stating "but are actually special" without an explanation of what "special" means in this context, and I don't think this article lead is the place to explain it. If there's a sensible way of integrating an explanation or a link to another article explaining what that means, that would work, but I think the phrase should just be deleted as it'll add confusion.
The "byte-per-byte" comment seems inaccurate: by my understanding, dd normally works at a block level, not a byte level.
Do you mean this to replace the entire lead section, or just the first paragraph?

—me_and 20:14, 4 April 2013 (UTC)

To reflect to your 5 points you pointed out.. If you did a comparison of what is currently on the introductory, the "quotation" pertains as the description "directly" from the manpage itself. The current introductory tries to distinguish between "normal" and "special" files, and by mentioning hardisks paths (/dev/sda /dev/sdb) is an improvement overlook of the already existing examples about the fact that dd works with "devices" directly rather than just ordinary "files". Laymen users seeing those paths /dev/zero and /dev/random are already not clear anyways, so a categorizing explanation is needed for them in very brief form-- They are not "normal" files -- The current form of the introduction also fails to mention all those files (/dev/sda, /dev/sdb, /dev/zero /dev/random) simply as "device files"-- This simplifies very much the understanding on what DD largely operates upon. You should understand that the current introductory form is already using "special files" but separates "device drivers for hardware (such as hardisks)" and "and special device files (such as /dev/zero and /dev/random)" on it's second sentence which is absolutely inaccurate since "hard disks" are device files-- and leads to assumption that hard disks are not device files (and since this is a UNIX article, think about the people reading this article anyways.. it would be reading UNIX users, and not your average Windows GUI desktop user -- Plus the fact I'm offering to merge or rename this article to make it even better for including Windows users -- in either case it's continually connected for what is a device file. If the device file concept is not caught then explaining dd is meaningless.) Also it is absolutely insignificant to include paths such as /dev/zero and /dev/random, as these non-storage devices are largely not used or of primary importance to the command dd at all, and strange that you did not bring that up. If I wanted to replace everything I would subtract using these two device files mentioned from the introductory. Also I was trying to be lenient in keeping alot of the elements already expressed in the current indroductory, but they are poorly expressed which leads to technically accuracy-- Even though it's not by goal to correct the entire page, the introductory should at least be simple and to the point. So if nobody minds, I would subtract those seldomly used device files from it's introductory. /dev/zero and /dev/random ARE NOT SOURCES for "convert and copy a file" in context of between being called a "data" file as expressed in the current introductory. The current introductory mentioning the expression 'data files' for device files is totally inaccurate -- which is why there is a link to file-- everybody can relate to "normal" files and "file" written by itself is sufficient to grasp the defacto definition of it. "file" is not to be taken "literally" by the lay user by that "quotation" -- and since it is fine for me to keep that quotation it MUST be properly interpreted, otherwise technical inaccuracy ensues. That is why there is emphasis to include MANPAGE on the very first sentence. And this is the reason why there's a mention of "storage experts", because this command is not meant to be used by regular users. To emphasize again since you still would debate this and for those who do not use UNIX-like systems, the word file as written within these quotes should not be taken literally as a "normal file". This fact of reality makes the manpage of 'dd' very difficult to understand but simplified in my revised introductory because it is largely and "implicitly" correlated to "special files" primarily. This is especially with the "dd" command and any other form of Unix-like system command that can work as a [Dump (storage dump) | storage dump tool]. This is also the reason why this "interpretation" of "files" as "device files" had to be recognized, especially to people who are new to the concept of byte-per-byte cloning whether from device sources directly or from files sources-- and in order to diverge confusion. Another thing, is the operation descriptions of the current introductory is inaccurate. When dd is operating conversion(text encoding) files, these files are not special files, as this form of operation relates to data files; article incorrectly implies that 'data' files and 'special files' do not need to be distinguished -- pertaining to ("The dd program can also perform conversions on the data as it is copied, including byte order swapping and conversion to and from the ASCII and EBCDIC text encodings." from current article). The current introductory is absolutely inaccurate, even in relation to non-Unix systems to assume that a "data" file, or "data" is an emphasis when copying byte-per-byte cloning with the dd command. Byte-per-byte is more accurate for explaining about dd, since "block-level" against non device files immediately leads to confusion to users as to whether or not dd can only copy from device sources directly-- this simply is not true-- and in which on the article page, only one out of more than a dozen has a normal file being used as a source-- so the argument about not emphasizing on device files is not a strong one. By using expression byte-per-byte, minimizes confusion as to describe dd it can work with BOTH device and non-device files. Another thing is the current introductory completely misinforms the reading user that device file sources are taken to be "data files" -- this is simply inaccurate. When a device file is cloned and stored into a normal file, it is not seen as a "data file" but a dump; (This is why I'm working offline on two more articles called Dump (Computer science)/Dump (storage dump)') DD is irrespective of any data structure contained within the transfer of those bytes when performing byte-per-byte cloning (whether it's from device files or dump files). The current introductory is wrong because dd does not care about "data", and using the word "data" is largely inaccurate for it's stated purposes. The current introductory for dd treats "data files" and "Hardware" device files as the same-- this is wrong. The only time an operator of dd does care if its data(and is seldomly used anyways-- even the article as I mentioned earlier only contains 1 example of it out of 17 examples -- the rest of the examples are focused on device files as sources), is during the use of text encoding conversion from "data" files. The emphasis of the operation of dd is not on data files but on data-agnostic byte sources, whether they're files or special device files. Dd is a hardcore command, and perhaps you should tally the proposed change to normal users to see if they can understand what is being proposed than to assume the position of what you think seems properly user-friendly worded. The introductory I rewrote is in my interest to keep it simple but without compromising accuracy. The current introductory is very inaccurate and misleading and definitely needs to be re-edited. If nobody can come up with a competitive argument as to why I should not make the proposed change, I will update the article in several days..

"Do you mean this to replace the entire lead section, or just the first paragraph?" Just the first paragraph

The above text is clarification for anyone who'd like to see why I wish to make those changes.

(I give it a week for other people to have their say, thanks for your feedback)

Swestlake (talk) 22:25, 4 April 2013 (UTC)

I'm not going to read through that wall of text, I'm afraid. Can you trim it down and add some paragraph breaks? —me_and 17:05, 5 April 2013 (UTC)

Someone mentioned to me why byte and not block. Simply put, "byte-per-byte basis" < One can add an elaboration to this to expand this basis to "block".. The word placements can be easily upgraded to instead say "byte-per-byte block"-- but then the rest of the article would have to be revised to see if that expression is not confusing.. or perhaps "byte-per-byte group(known as block)" -- and there's a section for explaining 'block', but it can be clearer right from the start because the 'block' section comes down on the third place. People reading the article would definitely know what a byte is, it's basic computer science that's why byte-per-byte was used; the word block doesn't sound familiar..The other reason why byte-per-byte may be of relevance to mention in one of dd's operational modes (text conversion), is the fact that only character conversion occurrs on an byte basis-- where each byte is analysed.. I may have over-simplifed both operational modes, so I can understand the concern of saying byte-per-byte-- instead I would take note, and use the 'block', if I can propose with less confusion on

byte-per-byte group (known as a block)
and have that hyperlinked to the 'block' section below it

Swestlake (talk) 23:15, 4 April 2013 (UTC)

So link the first occurrence of the word "block" to Block (data storage). That allows the correct term to be used, while providing an explanation for the technical term. Honestly, I don't think this is particularly relevant information for the article lead in any case, and would be better in the body of the article. —me_and 17:05, 5 April 2013 (UTC)

Comment - The one part that stands out to me the most is the /dev/sda examples in the paragraph. Anyone who knows what /dev/sda is isn't going to need that listed as an example, and anyone who doesn't know what it is isn't going to be helped by that kind of clarification, and the same is true of the other /dev/* examples. I also agree with User:Meand about the "special" wording; it seems like something to avoid. - Sudo Ghost 18:48, 5 April 2013 (UTC)

I do think listing the special devices like /dev/random is useful, as without specifying them it wouldn't be obvious that you can use dd to do things like read a quantity of random data to a file/device. As you say, if you know what a hard disk is, you don't need to be told, but I don't think that extends to the other /dev/* devices. —me_and 19:01, 5 April 2013 (UTC)

Sorry, I didn't mean things like /dev/zero or /dev/urandom, but specifically the devices such as /dev/sda. - Sudo Ghost 20:38, 5 April 2013 (UTC)

update of proposal for first paragraph

Introductory (first paragraph) is highly inaccurate, so I'd like to propose the following change

In computing, “dd” is a common program for Unix and Unix-like operating systems whose manpage describes it's purpose as to "convert and copy a file."^[1] dd's instructions are meant to be read by storage experts where the terminology of file is not loosely interpreted. On Unix-like systems, hard disks (such as /dev/sda and /dev/sdb) and other device files (such as /dev/zero and /dev/random) appear in the filesystem like an ordinary file but are actually special(device files exclusively). The program dd reads and writes to these special device files on a block (or byte-per-byte group) basis. As a result, dd can be used for backing up portions of a hard drive such as its boot sector, rather than strictly cloning the entirety of the drive. dd can perform byte order swapping while copying bytes from device files, as well as from binary data files. dd can also convert text encodings of ASCII and EBCDIC formats, whereby device or binary files are not practically used for this mode of operation.^[2]

Swestlake (talk) 00:31, 5 April 2013 (UTC)

@SudoGhost, there's more of a problem than /dev/sda exemplified. I have already addressed this in fully by comparing the current form to the present proposed form for sentence #2. The use of "Hardware drivers" is not only inaccurate across platforms (including MsWindows needless to say) to be treated as a separate concept from device files, as expressed in the current form-- because /dev/random /dev/zero are absolutely trivial to the common usage purpose of dd and are therefore insignificant not only as "device files" but as "data files" as well, of which the already existing current form uses these terminologies. I have fully emphasized this but you still fail to see these inaccuracies even without mentioning /dev/sda nor /dev/sdb.

@Meand can you instead use a realname so that I can reference you like a normal person? It feels that everytime I type your name I'm typing to a bot. So please. I even invited you for your criticism on my proposal for change-- I believe this is the way wikipedia should be run because I don't believe in changing things just like that without some feedback. It's a good idea to keep things onwards down-- but you had a fair criticism there about using byte-per-byte and decided to add back the "block" word but place byte-per-byte in parenthesis. I explained why I decided to express byte-per-byte -- mainly for simplifying the the character conversion mode of dd, which doesn't do it on block by block.. but the main operation for using dd is not character conversion -- in which I have already emphasized that it is only associated with one example out of the existing 17 ones(the article hosts 17 living examples placed there by not me on top of that).. So it'll be more adequate to focus on the main practical operations that dd is used for, just as it is exemplified on the rest of those 16 examples as well as in the real world where dd is used. It is possible also to use dd as a byte-per-byte with the size of the block being the size of a byte, but as I have already explained previously, the 'block' terminology is not a basic computer science term without the association that it's just another way of expressing a collection of bytes (and in sequence)-- also the 'block' is confusing in the current article form since it is not explained until the third section(existing article). So having a link to the third section was added to fill in any question about what 'block' is. I did not add the 'Block' explaining section, it was already there, and must of been for a reason. The word 'Block' makes no sense in itself in the introductory, and at least a hint on a fundamental terminology of 'byte' is immediately comprehensible, within a mere associated expression ('byte-per-byte group') linking to the 'Block' explanation section. Intuitively the user can immediately understand that a "block" refers as a sequential group of bytes and they wouldn't even need to click on the link for extra clarification. The current article 1) has no link to block, and 2)Many other reasons which I already address in that response you call "wall of text" -- Sorry if you do not want to challenge it-- But I address why using "block" without a mere hint/explanation of it is actually confusing on top of what I have already briefly just discussed herein. The block word stays, but it should have at least a reference to it or something associated with it that the user can understand

Swestlake (talk) 03:45, 6 April 2013 (UTC)

The word 'block' is used before section 3, and in Section 'Usage'. This also a reason why I do not see the point of having 'Usage' placed before the explanation of 'Block'. Having a link explanation to 'block' sooner guarantees the user understands what he's reading about

Swestlake (talk) 03:56, 6 April 2013 (UTC)

Just a tip, it doesn't help your cause when you tell others that they "fail to see" something. My point had nothing to do with "common usage", only that it isn't helpful to mention /dev/sda in the lede, for the reasons I gave. My observation went no further than that, but if someone "fails to see" something, that's an indicative of an issue with the proposed lede itself. - Sudo Ghost 05:46, 6 April 2013 (UTC)

@SudoGhost Sorry if mentioning "you fail to see" something isn't in your favorable wishes of how you'd like your concerns to be completely addressed, but that expression had absolutely nothing to do with my proposition therein other than having to re-iterate the basic argument point that I had to repeat twice to you on why my change-proposals "should be upholded". You overlooked it before and so that's why I meant by you "failed to see", whether you actually read my initial response for all those who wish to see all the reasons why I'd like to support my changes, or whether clarifying on why I had to re-improvise something that wasn't read in the first place is not an argument and doesn't render to any discussion as to invalidate my expressed arguments. "You fail to see" has nothing to do with upholding my proposition for the sake of upholding it, but rather by value of "argument" and point-by-point analysis and most importantly for upholding the validation of TECHNICAL ACCURACY. (You still never compare as to the technical INACCURACY OF THE CURRENT ARTICLE.) I actually made it simpler for you to perceive what I was trying to get through to you by merely saying "you fail to see" as an illustrative coherence in reference to the expression "point-of-argument"(as your quote of concern). The discussion is not for befriending people, learn how to argue your points.) You cannot win an argument by "merely" expressing your argument with the word "seems", which you have above. Using the word "seems" means you are uncertain. This is not a winning convincing argument. You didn't bring anything new that I did not address other than saying you "agree" with someone. Which again you didn't read moreover on this other person's argument, because you're not addressing the argument itself.. and an argument which I counter-argued in the "wall of text" that other person didn't want to read anyways. So you didn't bring anything that could convince me in seeing things in a better light. I did re-consider the word "block", but I explained as to why it is very problematic and why I initially thought of reducing to not using that terminology but rebrought it. What you concerned me with has already been addressed. Either you didn't read what I typed, completely missed the point, are not very adequate on the full operations of dd, or would like to have an opinion as from the point of a regular user.. you did not emphasize NOR realize that the current article is INACCURATE. I have not seen any counter-argument of analysis to compare technical accuracy between my proposed changes to the current existing article and I'm still waiting for that. It doesn't matter which point of view you use persay or try to make your argument to counter-argue my argument, your argument has to stand out to something I have not covered. Thanks for your concerns but you didn't bring in a strong argument to support your case to dissuade what I wish to propose changing.

Swestlake (talk) 08:26, 6 April 2013 (UTC)

Please see WP:TLDR and WP:BATTLEGROUND, you're not going to get a consensus for your changes that way. Your preferred changes don't improve the article; do you have a source that says what the file is "meant" for? You don't know what others did and did not read, that seems unnecessarily confrontational; Wikipedia is not a place to argue but a place to collaborate. I did read what you wrote, it was just not a convincing statement. The wording you've proposed moved away from clarity and a concise lede, so it's not an improvement and shouldn't be introduced into the article. - Sudo Ghost 16:49, 6 April 2013 (UTC)

"Your preferred changes don't improve the article; do you have a source that says what the file is "meant" for? "

Already addressed. It is also hyperlinked from the start.

It's also lesser to do "consensus". It's being able to justify the change while keeping it simple and not compromising technical accuracy while keeping it to a beginner's level-- since wikipedia isn't meant to have articles read like a manual. I see what others have to say, since you're not willing to debate it..

You're also completely missing the whole point. I indicated from the whole start, that I do not wish to change the whole article but, only the FIRST paragraph, which is composed of 7 sentences, keeping the same referential elements. I was very lenient, and this pertains to collaboration. The referential elements are clarified and corrected. There's a difference between knowing what the article is about than merely guessing as to understanding the topic. If I'm going to have to prove I have computer degrees and certifications about computer science articles, then this would be my last attempt of trying to collaborate my viewpoints. The article is technically inaccurate, and I just need to change 7 sentences-- this is from my understanding of many years of being in the trade. So far you offered no argument to disclaim any accuracy I have been proposing.

Wikipedia:TLDR "Reasons for length, good or bad"

WP:BATTLEGROUND "Wikipedia is not a place to hold grudges, import personal conflicts, carry on ideological battles, or nurture prejudice, hatred, or fear"

Both have absolutely nothing to do with the discussion on an article's TalkPage. This is not neither a grudge-- and I have disagreed with Meanmd, and even PROVED that I rebrought back the term 'block' back in the introductory-change proposal-- and even initally indicated my reasons for having earlier placed it aside. So pretty much again, you are refusing to engage in any constructive-argument dialogue here. If you do not like the proposal of changes, then you have to debate it. It's simple as that. There is also not one single instance of my input that I have exhibit any form of "import personal conflicts, carry on ideological battles, or nurture prejudice, hatred, or fear"

Are you an editor? If you are, then I suggest you try to provide me with helpful references. So far I haven't seen a single one.. but an attempt to try "winning over" your exhibition of references that has absolutely nothing to do with the proposed changes.

Those two links Wikipedia:TLDR , WP:BATTLEGROUND , pertains to the actual "editing" of the proposed changes.

I have OPENED to allow discussing/debate of the REASONS in "support" of the changes based upon the "OPERATION" of dd. There's two things here-> Understanding how DD works. (Which is improperly exhibit on the article's first paragraph), and There's number two: The actual expression of the changes themselves. You fail to understand how "dd" actually operates. This is why you are unable to read or comprehend any of the reasons I mentioned. If you do not understand how dd works, there's no point in trying to understand why the "expressed" changes are more than "just styled" the way it is.

There's no "ideological", prejudice, hatred, or fear" mongering in my arguments. If you refuse to debate my "reasons", then at least convince me how my understanding on the operation on how dd works is INVALID. If you cannot convince me that I am "WRONG" on the operation how dd "works" then I do not see any INVALIDITY of my proposal of change. You are very welcome to bring in any number of people to review the proposal. If you want to be "fair", I suggest 50% of people reviewing the proposal to have a good computer science background and have used DD on UNIX. Honestly, do you use DD on UNIX? Be honest now..

Swestlake (talk) 01:15, 7 April 2013 (UTC)

This confrontational language isn't going to get you anything, and you're not going to get a consensus nor anyone willing to discuss the changes with you when you respond with that level of unnecessary hostility. WP:TLDR and WP:BATTLEGROUND do not pertain to editing the changes, they pertain to this discussion. You have no consensus for your edit, so it's not going to be placed in the article without it. Civility is not optional nor is your reasoning convincing in the least, so you're not going to change the lede with that kind of response. As for the "do you use DD", my contributions will reflect that but if you need to understand the subject in order to understand the lede you proposed, then that it a critical error with the lede, not the reader. I know you meant that to support your argument, but it only makes the lede seem inaccessible to most readers, which defeats the purpose of having a lede. - Sudo Ghost 02:00, 7 April 2013 (UTC)

You are welcome to bring in a consensus. It seems to me that you are very unwelcoming in being openly debative about "inviting" others.

"but it only makes the lede seem inaccessible to most readers,"

This is your opinion. You do not speak for the UNIX community. So far you have not demonstrated to me you are in the trade? How is that a hostility knowing that "dd (Unix)" is actually meant for Unix users?-- in which by I have been offering to provision additional changes for non-UNIX users? Your counter-argument still falls short for speaking on a greater totality than the article's targetted readers of choice. It seems that any response I give you will have something to rather "say" than to rather "uphold" your position on a debative level. I do not see how you can provide anything meaningful to say to me. The only thing "hostile" as what you're trying to put it, is you do not want to debate it. Nothing I can do about that, sorry.

Swestlake (talk) 16:37, 7 April 2013 (UTC)

You still don't get the point, so there's no reason to continue this discussion. You have no consensus for your problematic proposed changes and so it won't be in the article. Next time try discussing your edits on their own merits instead of attacking others, otherwise this is a pattern that will repeat itself. - Sudo Ghost 00:03, 8 April 2013 (UTC)

For the record, I agree with everything SudoGhost has written above.

I will note that this is not the forum to discuss my username. If anyone wants to discuss that, please do so on my talk page. —me_and 18:36, 8 April 2013 (UTC)

Proposal for change - ( S.Westlake editorial suggestions )

In computing, “dd” is a common program for Unix and Unix-like operating systems whose manpage describes it's purpose as to "convert and copy a file."^[1] dd's instructions are meant to be read by storage experts where the terminology of file is not loosely interpreted. On Unix-like systems, hard disks (such as /dev/sda and /dev/sdb) and other device files (such as /dev/zero and /dev/random) appear in the filesystem like an ordinary file but are actually special(device files exclusively). The program dd reads and writes to these special device files on a block (or byte-per-byte group) basis. As a result, dd can be used for backing up portions of a hard drive such as its boot sector, rather than strictly cloning the entirety of the drive. dd can perform byte order swapping while copying bytes from device files, as well as from binary data files. dd can also convert text encodings of ASCII and EBCDIC formats, whereby device or binary files are not practically used for this mode of operation.^[2]

Swestlake (talk) 18:27, 7 April 2013 (UTC)

According to others who have posted on this talk page

"I learned to know dd way back in my early Unix days as a tool "to dump disk data to a file" and vice versa and I think, that suggests the most convincing explanation of its name dd = disk dump.--BerlinSight (talk) 18:41, 22 December 2012 (UTC)"

Is in agreement to what I have mentioned in dialogue. The emphasis that dd is a "dump" tool. This warrants the validity of my argumentative statements that "dd" is primarily used as a dump tool and not a character-conversion tool.. hence allowing dd to be seen as described should be clear right from the start.

Another user posts, "as i learn linux command "dd stands for 'disk dump'" is easy to remember , why not put it in the article so , new beginners can have a idea of it.Wanzhang (talk) 13:58, 4 July 2012 (UTC)"

Is strongly very much the concern I elaborated, but I disagree on using the confusion expression 'disk dump'. There is a much simpler way of getting this message across to which I have addressed so that even non-Unix users can understand. And that is to point that dd is can backup portions as well as strictly cloning an entire disk, instead of using the non-intuitive word of 'dump'. Is critical to mention in the introductory as that's what dd is primarily used for.

There is no reason why I would have to bother further to invite more people in understanding this viewpoint, but I'm still listening. This makes at least three people vs two editors who do not want to moderate this change, all from different time frames and already existing way above somewhere on this talk page to which they did not get any replies.

The proposal for change can be further validated by inviting third-parties as to determine whether the expressions therein the proposal is comprehensible. Therefore I have added this invitation to Wikipedia:3O, since there is no technical debate other than the disagreement of the chosen expressions for keeping the editorial still comprehensible for all users.

If the proposed changes is comprehensible or not comprehensible, still feel welcome to reply. This is not a vote contest, and I thank you for taking your time in reading and providing any feedback.

Swestlake (talk) 18:27, 7 April 2013 (UTC)

There's no need for a second section, but the same issues exist:

There is no reason to give hard disk paths, as per above.
"actually special" is, as per above, too vague and puffed up to actually be a useful descriptor.
There's no reason to provide in-text attribution that the manpage describes the purpose; that is the primary purpose.
"dd's instructions are meant to be read by storage experts where the terminology of file is not loosely interpreted." is unclear in the wording and also inaccurate; who says the instructions are only meant to be read by "storage experts"?

Other than the last sentence, that appears to be the majority of the changes, but none of those appear to improve the quality of the article. - Sudo Ghost 00:16, 8 April 2013 (UTC)

Response to third opinion request:

The lead of this article needs help, that's for sure. But I believe that your proposal is a change for the worse.

From the Manual of Style entry on opening sentences, it seems to me that a proper lead would look something like this:

dd is a computer command in Unix and Unix-like operating systems whose primary purpose is to convert and copy a file.

I am not saying that this is exactly what the first sentence should be, but as of now, it starts off with "In computing, dd is..." which seems to be a little unnecessary. The first sentence I propose there is short, simple, and tells in one sentence what exactly dd is and what it does. Keep the lead short -- I would actually use that sentence as the entire first paragraph; make the rest its own paragraph. It seems that the next question that a reader would want to know would be why it's called dd, and what dd stands for. Commands in Unix-like systems tend to be descriptive but short: ex, man for manual, cp for copy. I would assume that dd would have a similarly simple explanation, but don't have the foggiest clue what it is. Knowing this would, for me, be the first key to understanding.

By way of information, it seems that this section title is not at all descriptive. "Proposal for change feedback S.Westlake" sounds at first shake like you're discussing a change to S.Westlake, presenting your feedback for it, but asking for peer review before actually posting the feedback. Jsharpminor (talk) 07:45, 8 April 2013 (UTC)

Agreed on all points. I'll make the specific change you've suggested, too. —me_and 18:40, 8 April 2013 (UTC)

The following is something I believe would be just for the first paragraph. I do not want to change the intent of the article, and what is contained therein is still left for editorial commenting. Jsharpminor, you're still invited to comment.. And altering the quotation marks is not something I did not think of-- I was lenient-- However it leaves the introductory inaccurate. I've wished to be lenient to pertain 'wording' to the current article-- but apparently it'll lead to further confusion-- instead I'm scrapping it out and replacing it because it'll be impossible for me to "have" a lead while not "compromising" simplicity and technical accuracy on the usage of dd. The form of expressing 'convert' primarily in it's first sentence is actually misleading despite what dd manpage dictates an instruction manual about. Writing articles on wikipedia should not have expressions like that of an instruction manual (see wikipedia guidelines)-- so I don't see it fitting to go by modelling introduction part of articles close manpages. dd's manpage can startup with any words that it wishes to, and so it's irrelevant to believe it can be used as a template for writing up wikipedia pages

Wikipedia:BEGIN#First_sentence

"If its subject is definable, then the first sentence should give a concise definition: where possible, one that puts the article in context for the nonspecialist. Similarly, if the title is a specialised term, provide the context as early as possible"

"If its subject is definable, then the first sentence should give a concise definition: where possible, one that puts the article in context for the nonspecialist."

According to wikipedia's guidelines, there is no mandatory rule that the beginning sentence cannot have specialized terms. So again I've been correct in being able to use specialized terms as complying with Wikipedia's guidelines. And no hostilities here, I'm still listening for any further editorial commentary. I'm glad there's been a second thought about the current introductory, and thank you for your consideration but it still falls short and I still stand by others who support using the 'dump' terminology. (two other people support my view as on this talk page)
"

In computing, “dd” is a standard program in Unix-like operating systems dedicated to dump operations. dd is a command used for dumping hard disks and files while bytes transferred are not modified. When dd is not operating in a dump mode, dd is either used for text conversion or byte order swapping in which, for both cases, data is actually altered while being copied. dd can 'dump' or 'copy' from virtual devices, but its primary use is for strict-cloning(dumping) the entirety of devices (such as a hard disk). dd is flexible to command copying segments of a device and as a result is capable of cloning portions of devices such as a hard disk's boot sector or a segment of a virtual device(such as /dev/zero or /dev/random). On the majority of it's operations, dd transfers bytes in terms of blocks with devices, and is seldomly used for converting text or byte order data.(latter operation modes relate as byte-per-byte rather than strictly blocksize)

"

, -minus last parenthesis

(I need to add web citation)

http://www.gnu.org/software/coreutils/manual/html_node/Common-options.html#Common-options

http://www.gnu.org/software/coreutils/manual/html_node/Block-size.html#Block-size

I'll revisit this talk page after I place up dump (Storage dump), or at least a proposal talk post for it -- and will link that talk page from here to demonstrate that the word 'dump' is actually a necessity and isn't considered a 'data' file -- The proposed introductory shies away from elaborating on these concepts, but helps maintain accuracy of how files are looked at in respect to commands like dd. The word dump is used throughout the computer industry (apple, ibm, etc, etc), and used for symbolizing a strict-cloning operation(no transformation as in dd's other operating modes) from a device to another device (whether the target is a file or directly to another device)

The word dump has been around for a long time.. and is being used by a large number of people when relating to the command dd and other tools that perform what dd essentially does which is a byte-per-byte strict cloning (other users on this talk page also mention it)

Swestlake (talk) 22:43, 8 April 2013 (UTC)

I think that we are mostly in agreement on theories... we only seem to disagree on the application of those theories.

I don't have a clue what dd actually is. I don't need to in order to tell you that a certain introduction is either clear or unclear. If it's a dump program, let it say so. If it's a copy program, let the article say that instead. In either case, let's let the article be clear about what we're talking about. The first sentence (dd is a command on Unix and Unix-like operating systems whose primary purpose is to convert and copy a file) does just that.

I further agree with you that dump is pretty much a well-understood term... perhaps we could hotlink the word "dump" for those who don't understand it? Also, saying it's a "standard program" seems like a good idea.

However, you're worrying a bit too much about exact technical accuracy in the first sentence. The first paragraph should provide a dirty summary of what we're talking about, not tell you exactly how to use it. Technical details are great later on in the article, but the lead should be somewhat pared down. Accuracy is important, yes, but let's just have a short first paragraph that defines the term in the broadest of subjects without getting too detailed.

Apropos of nothing, it doesn't matter how many people agree with you... we need to form consensus and general agreement, not take votes to steamroll people's opinions. Also, perhaps I should thank you for inviting me to stay in the discussion? Jsharpminor (talk) 01:05, 9 April 2013 (UTC)

@Jsharpminor
I believe you mean "theory" as guidelines. I believe not everybody knows the flexible application of the many guidelines wikipedia has and it has guidelines scattered sometimes. I already said on prior occassions this isn't a voting contest. Thanks for your say, but please wait until I can get an article drafted for the other, it'll be easier to discuss things when I get it drafted.. this way a specialized term can be used in respect to Wikipedia's guidelines.
Wikipedia:BEGIN#First_sentence

"If its subject is definable, then the first sentence should give a concise definition: where possible, one that puts the article in context for the nonspecialist. Similarly, if the title is a specialised term, provide the context as early as possible"

"If its subject is definable, then the first sentence should give a concise definition: where possible, one that puts the article in context for the nonspecialist."

According to wikipedia's guidelines, there is no mandatory rule that the beginning sentence cannot have specialized terms. I'm glad there's been thought about the current introductory, and thank you for your consideration but it still falls short and I still stand by others who support using the 'dump' terminology. (two other people support my view as on this talk page).
Jsharpminor you're welcome for feedback, this would make you the 4th person in saying the same thing about the possibility of using 'dump' in the introduction. And again let me rephrain, this isn't a voting contest, but common sense what dd's introduction can pertain to
Swestlake (talk) 18:49, 10 April 2013 (UTC)

(no heading)

Kudos to whoever wrote the "fear and loathing" section. Nice to see that humorous content *can* make it into Wikipedia.

dd is a really cool program! :)

212.202.77.70 20:23, 15 May 2004 (UTC)

What does the name actually mean? dd = "disk dump"? Nixdorf 20:31, 2005 Jan 21 (UTC)

Probably not. See this old discussion from alt.folklore.computers for a discussion. It looks like "dd" ultimately stands for "data definition". --MarkSweep 02:28, 22 Jan 2005 (UTC)

The name section mentions "gallows humour", but I can't see any explanation of why the name dd is gallows humour. As a big fan of obscure nerd humour, I'd love to see this expanded. stib (talk) 06:15, 19 November 2007 (UTC)

as i learn linux command "dd stands for 'disk dump'" is easy to remember , why not put it in the article so , new beginers can have a idea of it.Wanzhang (talk) 13:58, 4 July 2012 (UTC)

Personally, since I work with z/OS and its JCL every day, I really fail to see the resemblance between 'dd' (Unix) and 'DD' z/OS apart from the two letters and that they have something to do with data, they have nothing in common. The entry in the Jargon File is purely from ignorance or misplaced superiority. — Preceding unsigned comment added by 15.195.201.90 (talk) 04:38, 23 May 2014 (UTC)

Linux or gdd specific behavior does not belong to generic WP examples

gdd specific is that count=0 has effect, other dd implement count=0 ~ infinity.
conv=fdatasync is gdd spüecific and thus does not belong into generic examples either
Linux specific is that lseek(2) may modifiy files (by seeking beyond the end of a file that was open for read/write). On a normal UNIX, an empty sparse file can only be created with the ftruncate() call that is not in any known dd implementation.

This was the reason why a related example has been removed from the article. Schily (talk) 12:59, 18 December 2014 (UTC)

Hello! As it seems, that behavior of lseek() isn't Linux-specific, and lseek() itself doesn't modify the file by seeking beyond its end. Please have a look at the Open Group's man page, which says this:

The lseek() function shall allow the file offset to be set beyond the end of the existing data in the file. If data is later written at this point, subsequent reads of data in the gap shall return bytes with the value 0 until data is actually written into the gap.

That's pretty much the same what both the Linux man page and FreeBSD man page say. Am I missing something? — Dsimic (talk | contribs) 14:53, 18 December 2014 (UTC)

Sorry, I have to correct myself. I thought that on Linux, gdd can create a sparse file using the removed example because the syscall chain: f = open("name", O_RDWR|O_CREATE|O_TRUNC), lseek(f, offset, SEE_SET), close(f) results in a sparse file of size "offset" while on other UNIXes, this just creates a zero sized file.

Correct is that gdd calls ftruncate() with count=0 which is still non-standard. A related example would need to be marked gdd specific. You may like to check the UNIX (OpenSolaris) dd source at: https://sourceforge.net/p/schillix-on/schillix-on/ci/default/tree/usr/src/cmd/dd/dd.c You may verify that there is no ftruncate() call inside and that is related to the seek=n parameter (there is however a Solaris specific oseek=n parameter - not available with gdd - that is related to ftruncate()). You may also verify that count=0 results in no record limit on Solaris, so the removed example is at least gdd specific. So on Solaris and other UNIXes, the removed example would have created an infinite sized non-sparse file. Schily (talk) 15:31, 18 December 2014 (UTC)

Non encyclopedical text in section Data recovery

Could someone explain the reason for this anecdotic text full of false claims?

Here are some basic facts:

GNU dd did not exist in 1984! (the first release of GNU dd is from 1992)
There have been of course older rescue programs than ddrescue (e.g. my sdd from 1984).

Background: In 1992, Richard Stallman asked for a free dd implementation in the USENET as he believed that no such implementation exists. At that time, I was thinking whether I should donate my sdd program.

I wrote sdd in 1984 (as a dd replacement) and as I worked for a company that made UNIX computers at that time, I had to deal with dying disks and to find solutions to recover data from such disks. I enhanced sdd to do this work.

The section in question should be corrected to meet historical facts or removed.

People who write articles in Wikipedia should first do their homework and inform themself about the background facts for an article. Schily (talk) 11:13, 20 January 2015 (UTC)

The 1984 date is suspect; the initial commit of dd.c in GNU coreutils gives an initial copyright date of 1985 (see source and log. However (like your own work before the mid-1990s), I have found no publicly available copy of the source which one could study. A better response would have been to point out the BSD version of dd, which it is easy to demonstrate that it predates either of these unpublished sources. TEDickey (talk) 01:14, 21 January 2015 (UTC)

Hello! Until we have other reliable sources available, the best we can do is to stick to available sources as closely as possible. As already discussed, having reliable sources for the events and software releases back from the 1980s and early 1990s is quite tough. — Dsimic (talk | contribs) 05:25, 21 January 2015 (UTC)

The BSD dd was derived from the AT&T UNIX V7 dd. The gdd sources have not been available before 1992, so they are most likely closed source.

Even the current text is unacceptable - it should not advertize for gdd while hiding the historic facts. Even the UNIX V7 dd had conv=noerror, so mentioning gdd here is an obvious attempt to slread false claims.

Finally the ddrescue command does not seem to be related to dd (see ddrescue WP article...) and the related text (if ever) should stay in the ddrescue article. I don't like to see bloated advertizing for an unrelatedprogram in the dd article and I don't like to see text that is proven wrong by reliable sources. Schily (talk) 13:12, 21 January 2015 (UTC)

Went ahead and trimmed it down a bit. Regarding the timeline, that's all nice, but please provide reliable sources. That's how Wikipedia works: we're summing up reliable sources, and unfortunately our own memories can't be used for that purpose. — Dsimic (talk | contribs) 13:39, 21 January 2015 (UTC)

Where exactly do you believe that reliable sources are missing? And for the rest, just naming the problem is more than enough for an unrelated program line ddrescue. People who are interested to read the related article may read there. There is no need for bloated advertizing in this article and this is of course not the intention of Wikipedia as well. Schily (talk) 14:31, 21 January 2015 (UTC)

For example, which reference covers that "the BSD dd was derived from the AT&T UNIX V7 dd"? — Dsimic (talk | contribs) 15:14, 21 January 2015 (UTC)

Limitations as reported by seagate

The quote from Seagate about the limitations of dd are verifiably incorrect. dd has always used the high-level device files starting with Research UNIX V5 when it was introduced. If there are no objections, I'd suggest removing the part about dd potentially not supporting 48-bit LBAs and rewriting the part about Linux's dd using device files to UNIX's dd in general using device files. — TavixVi (talk) 01:40, 12 May 2019 (UTC)

Too specific to GNU version of dd

This page seems to be too specific to the GNU coreutils version of dd. Given dd is a standard unix tool, this page should not act as if the GNU version is the canonical implementation of dd. Other implementations of dd are still widely deployed.210.56.230.226 (talk) 00:32, 18 December 2019 (UTC)

^ ^a ^b ^c Bell Laboratories. "dd man page". Retrieved 2009-02-25.
^ ^a ^b ^c Sam Chessman. "How and when to use the dd command?". CodeCoffee. Retrieved 2008-02-19.

[Unix-V7-man-1] Bell Laboratories. "dd man page". Retrieved 2009-02-25.

[tfl-dd-2] Sam Chessman. "How and when to use the dd command?". CodeCoffee. Retrieved 2008-02-19.

[1]

[2]