“Reawakeng" of an old issue with the "copy" command that I'm not sure I've ever reported in the past

[mathewsdw]

“Reawakening" of an old issue with the "copy" command that I'm not sure I've ever reported in the past...

I believe I've run into this issue in the past, but I’m also pretty sure that I did not bother to report it at the time. And I ran into it yet again in "researching" the "@Index" issue (previously posted), so this time I am “correcting” that deficiency. So there is no absolute no possibility whatsoever of any confusion, I will illustrate the exact steps to the exact problem in excruciating detail.

So, in Take Command/TCC I executed the following commands:

CDD “D:\Downloads\Firefox Downloads”
MD “Z:\Dataram_RAMDisk_v3.5.107” /D
Copy D:Dataram_RAMDisk_V3.5.130R18.msi .
FC /B D:Dataram_RAMDisk_V3.5.130R18.msi Dataram_RAMDisk_V3.5.130R18.msi
(files were different)
Copy D:Dataram_RAMDisk_V3.5.130R18.msi Dataram_RAMDisk_V3.5.130R18II.msi
FC /B D:Dataram_RAMDisk_V3.5.130R18.msi Dataram_RAMDisk_V3.5.130R18II.msi
(files were again different)
FC /B Dataram_RAMDisk_V3.5.130R18.msi Dataram_RAMDisk_V3.5.130R18II.msi
(files were different yet again)
D:
Copy Dataram_RAMDisk_V3.5.130R18.msi Dataram_RAMDisk_V3.5.130R18II.msi
FC /B Dataram_RAMDisk_V3.5.130R18.msi Dataram_RAMDisk_V3.5.130R18II.msi
(files were yet [B]again[/B] different)

So I then wrote a batch file with the following contents:

@Echo fc /b "Z:Dataram_RAMDisk_V3.5.130R18.msi"   "Z:Dataram_RAMDisk_V3.5.130R18II.msi"  >Z:RAMDiskDiffs.txt
      fc /b "Z:Dataram_RAMDisk_V3.5.130R18.msi"   "Z:Dataram_RAMDisk_V3.5.130R18II.msi" >>Z:RAMDiskDiffs.txt
@Echo fc /b "Z:Dataram_RAMDisk_V3.5.130R18.msi"   "D:Dataram_RAMDisk_V3.5.130R18.msi"   >>Z:RAMDiskDiffs.txt
      fc /b "Z:Dataram_RAMDisk_V3.5.130R18.msi"   "D:Dataram_RAMDisk_V3.5.130R18.msi"   >>Z:RAMDiskDiffs.txt
@Echo fc /b "Z:Dataram_RAMDisk_V3.5.130R18.msi"   "D:Dataram_RAMDisk_V3.5.130R18II.msi" >>Z:RAMDiskDiffs.txt
      fc /b "Z:Dataram_RAMDisk_V3.5.130R18.msi"   "D:Dataram_RAMDisk_V3.5.130R18II.msi" >>Z:RAMDiskDiffs.txt
@Echo fc /b "Z:Dataram_RAMDisk_V3.5.130R18II.msi" "D:Dataram_RAMDisk_V3.5.130R18.msi"   >>Z:RAMDiskDiffs.txt
      fc /b "Z:Dataram_RAMDisk_V3.5.130R18II.msi" "D:Dataram_RAMDisk_V3.5.130R18.msi"   >>Z:RAMDiskDiffs.txt
@Echo fc /b "Z:Dataram_RAMDisk_V3.5.130R18II.msi" "D:Dataram_RAMDisk_V3.5.130R18II.msi" >>Z:RAMDiskDiffs.txt
      fc /b "Z:Dataram_RAMDisk_V3.5.130R18II.msi" "D:Dataram_RAMDisk_V3.5.130R18II.msi" >>Z:RAMDiskDiffs.txt
@Echo fc /b "D:Dataram_RAMDisk_V3.5.130R18.msi"   "D:Dataram_RAMDisk_V3.5.130R18II.msi" >>Z:RAMDiskDiffs.txt
      fc /b "D:Dataram_RAMDisk_V3.5.130R18.msi"   "D:Dataram_RAMDisk_V3.5.130R18II.msi" >>Z:RAMDiskDiffs.txt

And here are the results of running that batch file:

fc /b "Z:Dataram_RAMDisk_V3.5.130R18.msi"   "Z:Dataram_RAMDisk_V3.5.130R18II.msi"
Comparing files Z:Dataram_RAMDisk_V3.5.130R18.msi and Z:DATARAM_RAMDISK_V3.5.130R18II.MSI
0000046D: 02 5C
0000046E: 65 A9
0000046F: CF D6
fc /b "Z:Dataram_RAMDisk_V3.5.130R18.msi"   "D:Dataram_RAMDisk_V3.5.130R18.msi"
Comparing files Z:Dataram_RAMDisk_V3.5.130R18.msi and D:DATARAM_RAMDISK_V3.5.130R18.MSI
0000046C: 40 70
0000046D: 02 48
0000046E: 65 AD
0000046F: CF 4E
00000470: F1 9A
00000471: 69 0B
fc /b "Z:Dataram_RAMDisk_V3.5.130R18.msi"   "D:Dataram_RAMDisk_V3.5.130R18II.msi"
Comparing files Z:Dataram_RAMDisk_V3.5.130R18.msi and D:DATARAM_RAMDISK_V3.5.130R18II.MSI
0000046D: 02 7C
0000046E: 65 07
0000046F: CF FE
fc /b "Z:Dataram_RAMDisk_V3.5.130R18II.msi" "D:Dataram_RAMDisk_V3.5.130R18.msi"
Comparing files Z:Dataram_RAMDisk_V3.5.130R18II.msi and D:DATARAM_RAMDISK_V3.5.130R18.MSI
0000046C: 40 70
0000046D: 5C 48
0000046E: A9 AD
0000046F: D6 4E
00000470: F1 9A
00000471: 69 0B
fc /b "Z:Dataram_RAMDisk_V3.5.130R18II.msi" "D:Dataram_RAMDisk_V3.5.130R18II.msi"
Comparing files Z:Dataram_RAMDisk_V3.5.130R18II.msi and D:DATARAM_RAMDISK_V3.5.130R18II.MSI
0000046D: 5C 7C
0000046E: A9 07
0000046F: D6 FE
fc /b "D:Dataram_RAMDisk_V3.5.130R18.msi"   "D:Dataram_RAMDisk_V3.5.130R18II.msi"
Comparing files D:Dataram_RAMDisk_V3.5.130R18.msi and D:DATARAM_RAMDISK_V3.5.130R18II.MSI
0000046C: 70 40
0000046D: 48 7C
0000046E: AD 07
0000046F: 4E FE
00000470: 9A F1
00000471: 0B 69

Notice that, put simply, every file in the sequence is different from every other file!

So I opened a "cmd.exe" session, and executed the following commands:

D:
CD "Downloads\Firefox Downloads"
Z:
MD "CMD.EXEDataram_RAMDisk_v3.5.107”
CD "CMD.EXEDataram_RAMDisk_v3.5.107”
Copy D:Dataram_RAMDisk_V3.5.130R18.msi .
Copy D:Dataram_RAMDisk_V3.5.130R18.msi D:Dataram_RAMDisk_V3.5.130R18II.msi
D:
Del Dataram_RAMDisk_V3.5.130R18II.msi
Copy Dataram_RAMDisk_V3.5.130R18.msi Dataram_RAMDisk_V3.5.130R18II.msi
Z:
Copy Z:\Dataram_RAMDisk_v3.5.107\fcDataramRAMDiskDiffs.btm fcDataramRAMDiskDiffs.bat

And ran the now ".bat" file:

fcDataramRAMDiskDiffs

with these results:

fc /b "Z:Dataram_RAMDisk_V3.5.130R18.msi"   "Z:Dataram_RAMDisk_V3.5.130R18II.msi"
Comparing files Z:Dataram_RAMDisk_V3.5.130R18.msi and Z:DATARAM_RAMDISK_V3.5.130R18II.MSI
FC: no differences encountered

fc /b "Z:Dataram_RAMDisk_V3.5.130R18.msi"   "D:Dataram_RAMDisk_V3.5.130R18.msi"
Comparing files Z:Dataram_RAMDisk_V3.5.130R18.msi and D:DATARAM_RAMDISK_V3.5.130R18.MSI
FC: no differences encountered

fc /b "Z:Dataram_RAMDisk_V3.5.130R18.msi"   "D:Dataram_RAMDisk_V3.5.130R18II.msi"
Comparing files Z:Dataram_RAMDisk_V3.5.130R18.msi and D:DATARAM_RAMDISK_V3.5.130R18II.MSI
FC: no differences encountered

fc /b "Z:Dataram_RAMDisk_V3.5.130R18II.msi" "D:Dataram_RAMDisk_V3.5.130R18.msi"
Comparing files Z:Dataram_RAMDisk_V3.5.130R18II.msi and D:DATARAM_RAMDISK_V3.5.130R18.MSI
FC: no differences encountered

fc /b "Z:Dataram_RAMDisk_V3.5.130R18II.msi" "D:Dataram_RAMDisk_V3.5.130R18II.msi"
Comparing files Z:Dataram_RAMDisk_V3.5.130R18II.msi and D:DATARAM_RAMDISK_V3.5.130R18II.MSI
FC: no differences encountered

fc /b "D:Dataram_RAMDisk_V3.5.130R18.msi"   "D:Dataram_RAMDisk_V3.5.130R18II.msi"
Comparing files D:Dataram_RAMDisk_V3.5.130R18.msi and D:DATARAM_RAMDISK_V3.5.130R18II.MSI
FC: no differences encountered

As is obvious, and unlike in TCC, all of the files have exactly the same contents, which is as one would expect!

I don't know that there is much I can add here except to say the last (and possibly only) time I had this problem I'm pretty sure I was also copying ".msi" files...

 

[rconn]

"Reawakeng" of an issue old with the "copy" command that I'm not sure I've ever reported in the past...

I think it is exceedingly unlikely there's a problem with COPY in TCC, for
two reasons:

1) EVERYBODY would be reporting it, not just you, and

2) TCC doesn't do the copies anyway -- it calls the Windows CopyFile API to
do everything.

I suspect the problem is most likely with your ramdisk or redirector. Is
your ramdisk formatted for NTFS?

Can you reproduce the problem when you copy to any other drive?

 

[mathewsdw]

Re: "Reawakeng" of an issue old with the "copy" command that I'm not sure I've ever reported in the past...

I think it is exceedingly unlikely there's a problem with COPY in TCC, for
two reasons:

1) EVERYBODY would be reporting it, not just you, and

2) TCC doesn't do the copies anyway -- it calls the Windows CopyFile API to
do everything.

I suspect the problem is most likely with your ramdisk or redirector. Is
your ramdisk formatted for NTFS?

Can you reproduce the problem when you copy to any other drive?

Rex, I don't disagree with the above in the slightest. However, the last time this happened I am about 90% sure it was also with a .msi file, and the problem I reported was exactly repeatable in the sense that bytes were different between the source and the destination files (I did it at least three times before I reported it) but the exact differences were, in fact, different in all cases, and, again, cmd.exe did not exhibit the problem doing exactly the same thing(s) to/from the same drive(s), and finally, and by far most importantly, the last example in the sequence I originally included in the original posting that started this thread (one that failed and which you apparently did not notice) was a copy from/to the same directory on my D: drive, which is a completely "normal", "ordinary", physical hard disk in my laptop! Finally, if you examine the results of executing the "file compare" batch file, the differences between the various "destination" files (the files copied to) are never exactly the same, but it was at almost exactly the same byte offset - the starting byte offset of the difference(s) varies by at most 1 byte, either 0x46C or 0x46D bytes, the "length" of the difference(s) was always either exactly 3 or exactly 6 bytes, but there were always, no exceptions, three bytes that compared differently starting at exactly the same bye offset (0x46D) into the file(s) in all cases!!! If you would like to do these test(s) for yourself, you are welcome, of course, to do so, although your results would absolutely not discredit mine (which I believe were proved by the original data I included, unless you really think that I am so mentally ill that I would make all of this stuff up)!!! As far as the file in question goes, it is a proprietary file that I (and quite possibly you) would be uncomfortable in sending you (and it's also quite large - about 3 megabytes), but said file is totally free and freely available on the web so if you want to know exactly where/how to get that file that would not be a problem - although publicizing that might "overwhelm" the vendor's website as other people downloaded said file to try to repeat said results, which is why I did not include that information in the first place.) As far as your using a Windows API function to actually do the copy goes, that, of course, makes it even less explainable if that is even possible, but it also in no way changes my results!!! And finally, and just to be complete about it because it really is completely irrelevant, yes, my RAM disk is NTFS formatted.

 

[rconn]

Re: "Reawakeng" of an issue old with the "copy" command that I'm not sure I've ever reported in the past...

No, I cannot reproduce your problem here, using .msi files, and copying
to/from a variety of drive types. (But no ramdisks, which I think are
useless nowadays when you could use an SSD drive instead.)

Are you sure you don't have an alias for COPY? (Which would explain the
different results for TCC and CMD, which otherwise use the same Windows
API.)

The only other possibility I can think of is you have some third-party app
hooking TCC (like an antivirus app or a disk monitor).

If anybody else is able to reproduce this I'll look into it further;
otherwise I'm inclined to attribute it to a peculiarity of your system.

 

[mathewsdw]

Re: "Reawakeng" of an issue old with the "copy" command that I'm not sure I've ever reported in the past...

Are you sure you don't have an alias for COPY?

Rex, while I do have a whole bunch of aliases, none of them are for the "copy" command; and I wouldn't do such a thing in a million years! And I have attached my complete list of aliases to this reply in a zip file so that you can check it out for yourself.

(Which would explain the different results for TCC and CMD, which otherwise use the same Windows API.)

On that I will be the first to admit that I don't have a clue. But the facts is the facts.

By the way, as a complete aside, I congratulate you because your "zip" command does a much better job of compression than any other zip program I've run into to date. In the past, when I was actually using a zip program on a regular basis (I don't any more because the freely available (on the web) "7zip" program almost always does a significantly better job than zip does, often by an order of magnitude or more, I don't really use zip much any more. (It does a much better job, I believe, primarily because of what is essentially an "architectural" issue - 7zip essentially uses one "dictionary" for all of the files of the same type in an archive, and there often is a lot of "commonality" between files of the same type)) I would periodically "find" and download and try other "zip" programs on the web, and the one I used to use on a regular basis was the one that did the "best" job (there's actually a somewhat amazing amount of "variation").) And again, your zip facility now falls into that category.)

But no ramdisks, which I think are useless nowadays when you could use an SSD drive instead.

And on this point, and I recognize that this is also purely an aside, there are several issues here. 1. SSD drives have a limited number of write cycles - were you even aware of that??? (You can look it up from many sources on the web if you really don't believe me. However, I will fully acknowledge that that "limit" is probably so high at this point in time that most people will never have to worry about it.) #2. SSD's are approximately an order of magnitude slower than RAM (from http://en.wikipedia.org/wiki/Solid-state_drive) #3. This is a laptop, and fooling around with replacing the (already there, of course!) internal hard drive is something I would really rather not do. #4. SSD's are significantly more expensive than traditional "electro-mechanical" disk drives (I don't have the figures right here with me at the moment, but I somehow doubt that you would disagree with that), and since I am multiply disabled and my income is severely limited as a result, that expense is something that I simply could not justify. (My RAM disk was and is entirely free; and it is using memory (out of almost 4GBytes of RAM on this machine) that I really wouldn't be using anyway.) #5. My RAM disk saves itself to a physical hard disk (in what is essentially a "disk image" file) on system shutdown, and reloads itself again on system startup, so it really isn't a matter of "saving" disk space per se, it is just the fact that RAM disk is, again, noticeably faster than a physical hard disk, and "fragmentation" is not at all an issue either for the RAM disk itself (because it is so fast, of course), nor for the physical hard disk because the RAM disk I am using, at least, re-uses the same physical hard-disk file on every system shutdown. Not only that, the RAM disk I am using has an option to save itself to hard disk periodically (to that same "image file"; and how often it does that is selectable by the user), so the amount of data one would lose on a "system crash" depends just on how long it was since the last automatic "save". And finally, Windows 7 has "crashed" on me exactly once since I installed it fairly quickly after it came out (I had Vista, and I think that you will not find it at all surprising that I found that OS to be actually disgusting so getting totally rid of it was a high priority), and I was doing something quite "unusual" at the time (I think installing some software I got off the web that I totally abandoned at that point of course.

The only other possibility I can think of is you have some third-party app hooking TCC (like an antivirus app or a disk monitor).

Rex, I am truly unaware of having any such thing. My "antivirus" app is the AVG anti-virus program, which I tend to believe is common enough that such things are not an issue, and the only other out-of-ordinary program I run, period, (excluding programs I wrote myself which are virtually always simple command-line programs that run quite quickly and then terminate and make no Window API calls at all) is Take Command/TCC!

If anybody else is able to reproduce this I'll look into it further;
otherwise I'm inclined to attribute it to a peculiarity of your system.

While I won't say I am completely happy with that, I will say that I fully understand it and I would probably have to do the same thing as you intend to do if I was in your position. In the future I will do two things when it is actually really important to me that the "copied" file is "valid" (for want of a better word): A. I'll do a file compare on it ("fc" command with the "/b" (binary) option, of course), and B: Redo the copy in cmd.exe if the copy did, in fact, fail.

And on on two completely separate and I believe quite humorous notes:

1. Yes, I use multiply-nested parenthesis a lot (as one thought leads to another related though leads to another....), and I don't quite know why I do that and nobody else that I am aware of does. However, since virtually everybody I "correspond" with by e-mail/whatever on a regular basis finds that quite humorous, so do I!!!! ; > ) >

2. You are really up checking this bulletin board kind of late, aren't you????? ; > ) >

 

[DMcCunney]

Re: "Reawakeng" of an issue old with the "copy" command that I'm not sure I've ever reported in the past...

On Sun, Sep 4, 2011 at 3:26 AM, rconn <> wrote:

> No, I cannot reproduce your problem here, using .msi files, and copying
> to/from a variety of drive types. *(But no ramdisks, which I think are
> useless nowadays when you could use an SSD drive instead.)

Ramdisks tend to be faster than SSD drives, and you use a ramdisk for
speed. ( I just ran across and old blog post from a software engineer
who uses a ramdisk for builds of a product for that reason.) In
addition, SSD drives cost money. If you have extra RAM to allocate to
one, you can get a decent ramdisk driver free.

I use a ramdisk because I run XP on a system with 4GB RAM. XP can
only see/use about 3.2GB of it. I went looking for things that
*could* use that .8GB of additional RAM, and found a ramdisk driver
that could. I have a 763MB ramdisk seen as a compressed NTFS
filesystem on Z: by Windows, and things work fine. That RAM would
otherwise be unused and wasted.

If I ran Win7, I'd drop the ramdisk, since 64bit systems *can* see the
extra memory.
______
Dennis

 

[David Marcus]

Re: "Reawakeng" of an issue old with the "copy" command that I'm not sure I've ever reported in the past...

Rex, I am truly unaware of having any such thing. My "antivirus" app is the AVG anti-virus program, which I tend to believe is common enough that such things are not an issue,

I don't think there is much chance that the problem is with TCC. So, you should try it without your antivirus and without any other programs that are loaded at startup. AVG is much more likely to be the problem than TCC is. Also, try safe mode. Do you always have the problem when copying from and to your hard disk? I.e., is it repeatable? Do you have another computer you can try?