Question Here's an odd one, copy not working

[Craig234]

I have a directory with files a little 1MB each. I type "copy somechars*.extension newname.extention", and it seems to work fine.

But the original file is over 1MB, and the new file is 100K. Repeated it a few times, typed in more of the original filename, no change.

 

[VirtualLarry]

I think that you are forgetting something important.

"copy" command, is text-oriented, not file-oriented, so much.

Either use "COPY /B" (the /B for Binary file), or use XCOPY, although I don't know if XCOPY can concatenate files, like you seem to be doing here with the COPY command.

 

[Craig234]

I think that you are forgetting something important.

"copy" command, is text-oriented, not file-oriented, so much.

Either use "COPY /B" (the /B for Binary file), or use XCOPY, although I don't know if XCOPY can concatenate files, like you seem to be doing here with the COPY command.

Thanks, but I don't think that's correct. I've copied this exact same file type many times the same way it's not working now (I'm only copying one file). As the web says, "The copy command allows users to copy one or more files to an alternate location. The copy command is used for complete files, if you want to copy a directory, or multiple directories containing files, use the robocopy or xcopy command."

 

[VirtualLarry]

Thanks, but I don't think that's correct.

Sorry, tried to help.

But let me tell you this, COPY command, without /B, will stop reading from a file, if it encounters a CTRL-Z (EOF) marker. Which are not uncommon in binary files.

Edit: Look at it this way, if what I am telling you is B.S., then why do they have the "/B" (Binary) option at all? Think for a bit.

Edit: Lastly, did you even try it, to see if it fixed the problem? Or just go to the web, to attempt to disprove me?

 

[VirtualLarry]

C:\Users\Admin>help copy
Copies one or more files to another location.

COPY [/D] [/V] [/N] [/Y | /-Y] [/Z] [/L] [/A | /B ] source [/A | /B]
     [+ source [/A | /B] [+ ...]] [destination [/A | /B]]

  source       Specifies the file or files to be copied.
  /A           Indicates an ASCII text file.
  /B           Indicates a binary file.
  /D           Allow the destination file to be created decrypted
  destination  Specifies the directory and/or filename for the new file(s).
  /V           Verifies that new files are written correctly.
  /N           Uses short filename, if available, when copying a file with a
               non-8dot3 name.
  /Y           Suppresses prompting to confirm you want to overwrite an
               existing destination file.
  /-Y          Causes prompting to confirm you want to overwrite an
               existing destination file.
  /Z           Copies networked files in restartable mode.
  /L           If the source is a symbolic link, copy the link to the target
               instead of the actual file the source link points to.

The switch /Y may be preset in the COPYCMD environment variable.
This may be overridden with /-Y on the command line.  Default is
to prompt on overwrites unless COPY command is being executed from
within a batch script.

To append files, specify a single file for destination, but multiple files
for source (using wildcards or file1+file2+file3 format).

 

[Craig234]

Sorry, tried to help.

But let me tell you this, COPY command, without /B, will stop reading from a file, if it encounters a CTRL-Z (EOF) marker. Which are not uncommon in binary files.

Edit: Look at it this way, if what I am telling you is B.S., then why do they have the "/B" (Binary) option at all? Think for a bit.

Edit: Lastly, did you even try it, to see if it fixed the problem? Or just go to the web, to attempt to disprove me?

Don't take it personally; you tried to help, I said thanks. My response was based on using copy for years for binary files, including the exact same file type, where this never happened before; and so yes, I checked and grabbed a web reference to get a 'second opinion', which says what I pasted, that copy is for files, with no mention of text.

You raise a fair question, though, about /b; I answered your rather insulting 'think for a bit' by checking xcopy, which was explained by being about multiple files/directories, but not the /b issue. You might well turn out to be right about that.

 

[Craig234]

Just re-tried it, same problem, to confirm nothing has changed; then with /b, and it copied the full file, which suggests you were quite right. I hadn't even looked at the command options for over a decade, so I'd forgotten there was a /b, as copy always has worked fine. Looks like you identified the issue as that , good going.

The command is a bit unclear. It has the /a for ASCII text files, and /b for binary files, but works without either, begging the question, how does it treat files then? It simply says 'file', and doesn't mention the EOF issue you identified.

 

[VirtualLarry]

You raise a fair question, though, about /b; I answered your rather insulting 'think for a bit' by checking xcopy, which was explained by being about multiple files/directories, but not the /b issue. You might well turn out to be right about that.

Ever think, that perhaps YOUR response was insulting to me, being an old-school DOS die-hard, and knowing these commands in and out, and you choosing (still?) to instead look up some web reference, rather than use the built-in HELP command in Windows COMMAND PROMPT, to look up the arguments (to the COPY command), to see if I was correct? And to do that, rather than simply actually TRY what I suggested, to see if it worked? Heavens no, we wouldn't want to actually get helped, it's more fun to complain that none of the suggestions work. :|

You think I'm insulting, when I give you the straight answer, and you refuse to accept it as correct; I think that sometimes, you're just trolling.

So, I guess, we'll have to disagree here. And try not to ban people that are helpful, and try not to insult them at the same time that they are helping.

 

[VirtualLarry]

Lastly, if you have been using COPY, WITHOUT the "/B" flag, to copy BINARY files, you may have just "gotten lucky", or more likely, you now have hardly-noticable bit-rot in some files. The reason being is, if the file DOES NOT contain a CTRL-Z (EOF) marker (ASCII character 26), then the usage of /B really most likely doesn't matter. But it's a good idea to use it for copying binary files, because that's what it's there for.

Edit: You can test this, with a text editor that allows you to insert control characters, or using a hex-editor, to insert some character 26 bytes, and then follow it with some text strings.

Use the COPY (without the /B) command, to copy that file to another file, and then try TYPE and then the destination file. See if that second string is present.

 

[VirtualLarry]

I mean, maybe I'm wrong about the defaults, being set to BINARY file-type by default, but I doubt that, as it would screw up a lot of programming command-line dev environments that began in the DOS world, that depend on that legacy behavior to use COPY to concatenate files in ASCII mode by default.

 

[VirtualLarry]

And if you try it, with the /B flag, and it works, then let me know. If it doesn't work, then you probably have some sort of hardware fault, possibly with the disk. Is this on the 5TB HDD that is failing in your system?

Edit: If you haven't ignored me yet, consider using the "/V" (Verify) flag, when doing COPY commands on disks that have errors. If you are trying to do this on your failing 5TB HDD, you should have probably mentioned that fact in the OP, AND, you should familiarize yourself with the "/V" option. It shouldn't be needed, on a properly-running system, but if you're paranoid about file-copies completing correctly, or have faulty / flaky drives, then use it.

 

[VirtualLarry]

Look, I'm not mad at you Craig, I'm a little irritated, because I gave you a straight answer, based on my years of DOS arcana, and you quote some (not linked) "web reference", that glosses over the specifics, and then you use that to claim that I'm wrong, rather than just trying what I suggested. You're hard to give tech-support to, you know?

 

[Craig234]

Ever think, that perhaps YOUR response was insulting to me, being an old-school DOS die-hard, and knowing these commands in and out, and you choosing (still?) to instead look up some web reference, rather than use the built-in HELP command in Windows COMMAND PROMPT, to look up the arguments (to the COPY command), to see if I was correct? And to do that, rather than simply actually TRY what I suggested, to see if it worked? Heavens no, we wouldn't want to actually get helped, it's more fun to complain that none of the suggestions work. :|

You think I'm insulting, when I give you the straight answer, and you refuse to accept it as correct; I think that sometimes, you're just trolling.

So, I guess, we'll have to disagree here. And try not to ban people that are helpful, and try not to insult them at the same time that they are helping.

What you got wrong was in saying that copy is 'text oriented, not file oriented'. That's not a very apt description, and contradicts years of using it on thousands of non-text files. Someone being helpful can also be insulting. If I wrote similar to your comment, I could say, 'copy isn't for text files. If it were, why is there the /a option? think for a bit.'

My error was in only looking at the xcopy part of your answer (which, to be accurate, was rather wrong also; and I wasn't concatenating files, either) and forgetting about the /b option you had correctly mentioned. It's insulting again as you suggest I don't weigh people helping versus other behaviors, as you make an accusation of trolling.

You've recognized before that sometimes you say things in ways that have issues, which I pointed out; at the same time you were trying to help, which I also pointed out.

When there are like 5 issues in as many sentences, that's an issue. The intent to help is being taken into account.

As I said in post 7, I did try it with /b, and that did solve it. This is on the brand new replacement disk. As I said, I think you correctly identified the issue as that EOF condition, which I wouldn't expect to be as rare as it is. I've copied dozens of similar binary files from the same program and don't recall any running into it before. Thanks again for helping.

 

[VirtualLarry]

As I said in post 7, I did try it with /b, and that did solve it. This is on the brand new replacement disk. As I said, I think you correctly identified the issue as that EOF condition, which I wouldn't expect to be as rare as it is. I've copied dozens of similar binary files from the same program and don't recall any running into it before. Thanks again for helping.

Oh, you did try it. I'm sorry that I accused you of trolling then. And I'm sorry I came across as insulting. I guess I knew what I was talking about, and when I gave you the answer in post 2, and then in post 3, you said that I was incorrect, because of some "web reference", well, I guess I felt insulted. That I was trying to help, gave you a straight answer, and it seemed to me that you were more interested in "proving me wrong" than solving the problem. I'm sorry that I came across as a "butt" again. It is a bad habit of mine.

 

[VirtualLarry]

Just re-tried it, same problem, to confirm nothing has changed; then with /b, and it copied the full file, which suggests you were quite right. I hadn't even looked at the command options for over a decade, so I'd forgotten there was a /b, as copy always has worked fine. Looks like you identified the issue as that , good going.

The command is a bit unclear. It has the /a for ASCII text files, and /b for binary files, but works without either, begging the question, how does it treat files then? It simply says 'file', and doesn't mention the EOF issue you identified.

Just a note, I wrote most of the following posts after post 7, before reloading the thread and reading post 7, so now I look like more of a "butt". Oh well.

Yes, HELP COPY could indicate that the default mode is ASCII, I think that depends on the "COPYCMD" environment variable as well.

Also, the command-line that you were using in the OP, with a wild-card in the source, and a single file as the destination, is indeed a command for file concatenation, if multiple files match the wildcard. If you don't want to concatenate files, but want to copy multiple files to a destination directory, read the help for XCOPY instead.

 

[Craig234]

Oh, you did try it. I'm sorry that I accused you of trolling then. And I'm sorry I came across as insulting. I guess I knew what I was talking about, and when I gave you the answer in post 2, and then in post 3, you said that I was incorrect, because of some "web reference", well, I guess I felt insulted. That I was trying to help, gave you a straight answer, and it seemed to me that you were more interested in "proving me wrong" than solving the problem. I'm sorry that I came across as a "butt" again. It is a bad habit of mine.

Ya, like I said, it wasn't personal; what happened was, I saw you mention copy as being for text files, and I thought, 'I've been copying binary files for years with it'. So I checked the syntax, and the description is, 'for copying files', with no mention (in the general description) of 'text files'. I didn't cut and paste the text to try to criticize your response, but just to say, 'see, here's why I'm saying it doesn't say text files'. To just post neutral info so we had common facts to discuss. And then I checked xcopy, which I recalled is an enhanced copy, and it was described as being about multiple files, which isn't the issue, here, and I posted at that point, forgetting the /b part of your post until you re-mentioned it.

And then I posted a clarification, about how the command is a bit confusing, given the /a and /b options both, not being clear whether it defaults to either, just saying "files", and no mention of the EOF issue.

It's not trying to 'prove you wrong' as the motive, but it was as I say above, responding to the 'text files' as appearing incorrect, partly because it was inconsistent with a lot of previous copies of binary files, though it seems to have turned out to be correct about the EOF issue, which I have no explanation for why that hasn't happened more often. Finally - no problem. And again good going identifying the EOF, /b issue.

 

[VirtualLarry]

What you got wrong was in saying that copy is 'text oriented, not file oriented'. That's not a very apt description, and contradicts years of using it on thousands of non-text files.

And I wasn't wrong there. The COPY command respecting EOF characters embedded in files by default DOES make it naturally text-oriented.

So, I guess that you were "just lucky" for years, or you have bit-rot that you never noticed.

 

[VirtualLarry]

I'm glad that we've come to a mutual understanding of the COPY command, finally.

 

[Craig234]

I'm basically shocked about the EOF issue. The copy command is so basic, and people copy binary files so constantly, that I find it hard to believe the default for it is to chop off binary files with an EOF (I'd still have to look up what the /a does for ascii files).

 

[VirtualLarry]

Well, perhaps I'm slightly wrong, and it doesn't just default to ASCII / text mode, but perhaps, it internally does something similar to the *nix "magic" command, which attempts to determine file-types through a heuristic, of examining the file's contents, to some degree.

Like, maybe it recognizes files with an "MZ" signature (executable files), and then defaults to "binary" mode to copy those files. But some filetypes (the unfortunate ones, as you found out), get interpreted as a "text" file, and then gets chopped off at the first EOF marker.

 

[Muadib]

Old school smackdown!!!! For a second I thought I traveled back to 1995.

 

[Craig234]

Old school smackdown!!!! For a second I thought I traveled back to 1995.

I don't think there was any 'smackdown' here. We discussed why suddenly a copy command that had long worked, didn't on one file.

 

[Muadib]

I don't think there was any 'smackdown' here. We discussed why suddenly a copy command that had long worked, didn't on one file.

One of you got a bit heated in the beginning, and it wasn’t VL....,

 

[Craig234]

One of you got a bit heated in the beginning, and it wasn’t VL....,

Looks like you're trying to project your personality issues onto people. Maybe you should find another thread.

 

[Muadib]

Looks like you're trying to project your personality issues onto people. Maybe you should find another thread.

Wow I guess Jack was right. You can’t handle the truth!