Welcome!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

SignUp Now!

"Reawakening" of an old issue with _complete_ documentation...

May
855
0
I do not have a clue as to what is going on here, nor do I know how "important" it is given that I know that it exists and how to easily circumvent it, but the following is complete, precise, documentation of the situation at hand:
HTML:
[D:\JP Soft Demo Directory]dir

 Volume in drive D is Data           Serial number is e4fa:ef04
 Directory of  D:\JP Soft Demo Directory\*

 9/18/2011  13:45             .
 9/18/2011  13:45             ..
 9/17/2011  23:53       3,141,120  Dataram_RAMDisk_V3.5.130R19.msi
         3,141,120 bytes in 1 file and 2 dirs    3,141,632 bytes allocated
     6,650,011,648 bytes free

[D:\JP Soft Demo Directory]md Test /D

[D:\JP Soft Demo Directory\Test]copy ..\Dataram_RAMDisk_V3.5.130R19.msi . /O
D:\JP Soft Demo Directory\Dataram_RAMDisk_V3.5.130R19.msi => D:\JP Soft Demo Directory\Test\Dat
aram_RAMDisk_V3.5.130R19.msi
     1 file copied

[D:\JP Soft Demo Directory\Test]fc /b ..\Dataram_RAMDisk_V3.5.130R19.msi Dataram_RAMDisk_V3.5.1
30R19.msi
Comparing files ..\Dataram_RAMDisk_V3.5.130R19.msi and DATARAM_RAMDISK_V3.5.130R19.MSI
0000046C: B0 E0
0000046D: 09 8E
0000046E: 15 33
0000046F: C4 36
00000470: 5F 33
00000471: 62 76

[D:\JP Soft Demo Directory\Test]del Dataram_RAMDisk_V3.5.130R19.msi
Deleting D:\JP Soft Demo Directory\Test\Dataram_RAMDisk_V3.5.130R19.msi
     1 file deleted          3,141,632 bytes freed

[D:\JP Soft Demo Directory\Test]cmd
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation.  All rights reserved.

D:\JP Soft Demo Directory\Test>copy ..\Dataram_RAMDisk_V3.5.130R19.msi .
        1 file(s) copied.

D:\JP Soft Demo Directory\Test>fc /b Dataram_RAMDisk_V3.5.130R19.msi ..\Dataram_RAMDisk_V3.5.13
0R19.msi
Comparing files Dataram_RAMDisk_V3.5.130R19.msi and ..\DATARAM_RAMDISK_V3.5.130R19.MSI
FC: no differences encountered


D:\JP Soft Demo Directory\Test>
At this point, I have done this literally dozens of times, with similar results (the reason I use the word "similar" is because the exact byte offsets and differences vary from test to test, although the byte offsets are always approximately (within one or two bytes) the same).

I don't want to "distribute" the file in question because I suppose it might be proprietary, but it is freely and readily available from http://memory.dataram.com/products-and-services/software/ramdisk, just click on the button on the far right at about the middle of the page "Download It Dataram RAMDisk (3.0MB)". And just to be "complete" about it, I ran "just-updated" copies of both "Malwarebytes Anti-Malware" (http://www.malwarebytes.org) and SpyBot Search & Destroy (http://www.safer-networking.org/en/index.html) before I made this posting, and no "malware" nor "spyware" were found; and "AVG Anti-Virus" is always present and running. And finally, drive "D" is a completely "ordinary" partition on the physical hard disk of my laptop (not RAMDisk).

TCC 12.11.74 Windows 7 [Version 6.1.7601]
 
At this point, I have done this literally dozens of times
Do you have the same problem if you do the test in a Windows Command Prompt?

If you do, the problem clearly lies outside of Take Command.

Charles.
 
Do you have the same problem if you do the test in a Windows Command Prompt?

I think that's what he was showing. Further down in the console output he subshells into CMD and gets different (correct) results from there. The problem was only in TC. For what it's worth, I tried the same thing without a problem (but using TCC 13.00.22 x64).

mathewsdw:

1. What happens if you use copy /V (verify)?
2. Can you reproduce the problem with other files?
3. Does it happen in other folders or partitions too?
 
I think that's what he was showing. Further down in the console output he subshells into CMD
Sorry, I missed that!

When you do the copy is it always the *same* bytes that are different or do they change with each copy?

Here are a few more things you can try:

Use VIEW to view the RamDisk file and the copy and then select MD5 from the Tools menu. Do the files have different MD5s?

Use the hex mode in VIEW (Alt+H) to inspect the bytes that fc reports as different. Are they as fc says they are?

When viewing the RamDisk file with VIEW, select Copy from the File menu to make another copy of the file. Is this file also different?

Charles.
 
1. What happens if you use copy /V (verify)?
2. Can you reproduce the problem with other files?
3. Does it happen in other folders or partitions too?
1. No difference. (Even though the "source" and "destination" files do not compare equally after the copy, no "messages" of any kind are emitted by the actual "copy" command. Although I've often suspected that the "/V[erify]" flag was, how shall we say, bogus.)

2. When I copy a file (or files), I absolutely never just copy the file(s), ever, under any circumstances whatsoever unless it's a completely unimportant file that I really don't care about, but in that case I probably wouldn't be copying it in the first place, and, in a similar vein, I never, ever, move a file to a different drive\partition, I copy it. So what's the point, particularly regarding the "move"? Simple, I am totally admittedly somewhat paranoid (more about mistakes I might have made than anything else; I have multiple "disabilities" including (but not limited to) (medically diagnosed) very bad memory, and difficulty reading, and I wrote a program many years ago that compares the "copies" to the file(s) that were "copied", and only delete(s) the file(s) that were copied (as in a "move") if they exactly "match" the final "cop(y/ies)". (The program has an option to not delete the "source" file(s) but only do the comparison(s) if, in fact, I really was only doing a "copy".) And it is through this program that I identified the problem in the first place, otherwise I would not have known that this was occurring. The "fc /b" commands in the original posting were only done to "verify" the results of my program so that my program was taken entirely out of the equation, so to speak.

3. This has happened exactly one time in the past; I am about 90% sure it was with a .msi file, and about 50% sure it was with (possibly an earlier version of) the same .msi file (one of the reasons for my recommendation for the readers of the posting to download it and verify it for themselves if they wished).

Just as a another note regarding my "paranoia", when I zip (or 7z, my "preferred" archiver), files, I then unzip/un7z them into a different directory (on the same drive) and then delete the files from the original director(y/ies) they came from using the previously referred-to program; if the original "source" directories still exist (my program deletes a directory if it removes all of the file and directories that were in it), it means that I made a mistake of some kind somewhere and I need to redo the process whole process from the beginning. In any case, I move the files back into their original directories from the "temporary" directory (again, on the same drive/partition) to restore things back to the way they were in the beginning. ("Moves" on the same drive/partition are pretty much completely "safe" because they only involve the "manipulation" of director(y/ies) and their entries, not anything really to do with the contents of the files involved.)

I am attaching said program to this posting, both the executable and all of the source files so anybody who looks can verify that it does not contain any viruses/malware/spyware/etc., and anybody who wants to is welcome to compile and link it themselves. Since many of the included "include" files were scattered all over my "development" directories in the "original" source and I "consolidated" them all into one "include" dirctory for the purposes of creating said zip file, I can not guarantee that there may not be some relatively minor "adjustments" that need to be made to get it to compile without error, although I really don't think that that will be the case. Also, the program is completely self-documented (I mean running it, not the code; although that is fairly well-documented also (I absolutely need good documentation because of my bad memory)), and the first time you run it after unzipping and placing it into a directory on your system (there are no associated DLL's so therefore there is no need for an "installation" program) it will tell you how to get "help". And just so there is no confusion, it is a command-line program (that works quite well under cmd.exe, also).
 

Attachments

  • DelDups.zip
    71.4 KB · Views: 327
Sorry, I missed that!

When you do the copy is it always the *same* bytes that are different or do they change with each copy?

Here are a few more things you can try:

Use VIEW to view the RamDisk file and the copy and then select MD5 from the Tools menu. Do the files have different MD5s?

Use the hex mode in VIEW (Alt+H) to inspect the bytes that fc reports as different. Are they as fc says they are?

When viewing the RamDisk file with VIEW, select Copy from the File menu to make another copy of the file. Is this file also different?

Charles.
Charles, you also missed the fact that it was a RAMDisk "installation" (.msi) file; none of the files involved were on a RAMDisk or had ever been on a RAMDisk, period, end of sentence. (If you look at the original TCC session, everything was done on my D: drive, and only my D: drive, which is a completely ordinary partition on an a physical hard-disk in my laptop.) I was very careful to take the RAMDisk itself completely out of the equation so that it could not have anything to do with the issue at hand.)

As far as your question about "always the same bytes?" goes, pretty much. The offsets of the first and last changed bytes (as well as the length of the series of changed bytes) can change from test to test, but there is always about a 3-byte sequence at always the same byte offset that is different. (And the bytes that are different are always sequential.) Also, the specific differences have never been the same on two "successive" tests; i. e. I can guarantee that test 5 returned different results than test 4, I can not guarantee that test 5 returned different results than test 1.

I have absolutely no reason to "distrust" the results as returned by "fc", particularly since my own program reported the same thing in the first place, which is exactly why I ran the "fc" program in the first place.
 
As far as your question about "always the same bytes?" goes, pretty much. The offsets of the first and last changed bytes (as well as the length of the series of changed bytes) can change from test to test, but there is always about a 3-byte sequence at always the same byte offset that is different. (And the bytes that are different are always sequential.) Also, the specific differences have never been the same on two "successive" tests; i. e. I can guarantee that test 5 returned different results than test 4, I can not guarantee that test 5 returned different results than test 1.

Does this only happen with files downloaded from the internet? How are you downloading them? Internet Explorer?

If you disable your antivirus and start the process from scratch (i.e. download another copy of the same file from the same site), does the problem still occur?
 
I've tried copying several different files, including other MSI files and I think there's something about that Dataram install file that TCC doesn't like. I can't explain it though. Here's CMD.
HTML:
C:\DL\x>dir
 Volume in drive C has no label.
 Volume Serial Number is 58B8-A853

 Directory of C:\DL\x

09/19/2011  10:42    <DIR>          .
09/19/2011  10:42    <DIR>          ..
09/06/2011  09:10         3,140,608 Dataram_RAMDisk_V3.5.130R18.msi
               1 File(s)      3,140,608 bytes
               2 Dir(s)  73,507,934,208 bytes free

C:\DL\x>copy Dataram_RAMDisk_V3.5.130R18.msi 1.msi
        1 file(s) copied.

C:\DL\x>copy 1.msi 2.msi
        1 file(s) copied.

C:\DL\x>copy 2.msi 3.msi
        1 file(s) copied.

C:\DL\x>copy 3.msi 4.msi
        1 file(s) copied.

C:\DL\x>copy 4.msi 5.msi
        1 file(s) copied.

C:\DL\x>sha1sum Dataram_RAMDisk_V3.5.130R18.msi 1.msi 2.msi 3.msi 4.msi 5.msi
32a7c5d65a0985965a2b1bdc36d90c308acd71b9 *Dataram_RAMDisk_V3.5.130R18.msi
32a7c5d65a0985965a2b1bdc36d90c308acd71b9 *1.msi
32a7c5d65a0985965a2b1bdc36d90c308acd71b9 *2.msi
32a7c5d65a0985965a2b1bdc36d90c308acd71b9 *3.msi
32a7c5d65a0985965a2b1bdc36d90c308acd71b9 *4.msi
32a7c5d65a0985965a2b1bdc36d90c308acd71b9 *5.msi
And then here's TCC (13.0.23)
HTML:
[C:\DL\x]
10:44:08 $ copy Dataram_RAMDisk_V3.5.130R18.msi 1.msi
C:\DL\x\Dataram_RAMDisk_V3.5.130R18.msi => C:\DL\x\1.msi
     1 file copied

[C:\DL\x]
10:44:36 $ copy 1.msi 2.msi
C:\DL\x\1.msi => C:\DL\x\2.msi
     1 file copied

[C:\DL\x]
10:44:44 $ copy 2.msi 3.msi
C:\DL\x\2.msi => C:\DL\x\3.msi
     1 file copied

[C:\DL\x]
10:44:50 $ copy 3.msi 4.msi
C:\DL\x\3.msi => C:\DL\x\4.msi
     1 file copied

[C:\DL\x]
10:44:54 $ copy 4.msi 5.msi
C:\DL\x\4.msi => C:\DL\x\5.msi
     1 file copied

[C:\DL\x]
10:44:58 $ sha1sum Dataram_RAMDisk_V3.5.130R18.msi 1.msi 2.msi 3.msi 4.msi 5.msi
32a7c5d65a0985965a2b1bdc36d90c308acd71b9 *Dataram_RAMDisk_V3.5.130R18.msi
85103b6d5807cbbe38065011587f3306e770fa5f *1.msi
508ae4992d55342b414db7874b8866f0e1f81225 *2.msi
8125e9614da922547606261c21c73132970d9a06 *3.msi
c5ec6fcf2092ee64a6fdbfc2290d2bc18d27886f *4.msi
cd926ae55f9a31a2a272dd7c9230d077c92706ae *5.msi

[C:\DL\x]
10:45:09 $ fc /b Dataram_RAMDisk_V3.5.130R18.msi 1.msi
Comparing files Dataram_RAMDisk_V3.5.130R18.msi and 1.MSI
0000046C: 70 C0
0000046D: 48 97
0000046E: AD A4
0000046F: 4E 08
00000470: 9A E3
00000471: 0B 76

[C:\DL\x]
10:45:36 $ fc /b 1.msi 2.msi
Comparing files 1.msi and 2.MSI
0000046C: C0 40
0000046D: 97 9B
0000046E: A4 7B
0000046F: 08 0D

[C:\DL\x]
10:45:49 $ fc /b 2.msi 3.msi
Comparing files 2.msi and 3.MSI
0000046C: 40 10
0000046D: 9B 53
0000046E: 7B 1D
0000046F: 0D 11

[C:\DL\x]
10:45:53 $ fc /b 3.msi 4.msi
Comparing files 3.msi and 4.MSI
0000046C: 10 00
0000046D: 53 41
0000046E: 1D 4C
0000046F: 11 13

[C:\DL\x]
10:45:57 $ fc /b 4.msi 5.msi
Comparing files 4.msi and 5.MSI
0000046C: 00 30
0000046D: 41 0B
0000046E: 4C 18
0000046F: 13 16
Notice how after the first copy, only four bytes are changing, but always at the same offset and never the same changes. If I copied the original MSI file to 5 different copies, then it would have been like the first example with six bytes changing.

I have no clue what's happening, just showing that the problem can be duplicated. I can zip up my copy of the MSI file and post it somewhere if you want it for testing.

I'm not running any plugins or using an alias for copy.
 
Looks like they released a new build: R19. Can someone post the older one somewhere? With R19, I don't see a problem:

HTML:
C:\Junk>dir

 Volume in drive C is TI105444W0C    Serial number is 709c:de9d
 Directory of  C:\Junk\*

 9/19/2011  12:59p        <DIR>    .
 9/19/2011  12:59p        <DIR>    ..
 9/19/2011  12:59p      3,141,120  Dataram_RAMDisk_V3.5.130R19.msi
         3,141,120 bytes in 1 file and 2 dirs    3,141,632 bytes allocated
   243,975,438,336 bytes free

C:\Junk>copy Dataram_RAMDisk_V3.5.130R19.msi 1.msi
C:\Junk\Dataram_RAMDisk_V3.5.130R19.msi => C:\Junk\1.msi
     1 file copied

C:\Junk>copy 1.msi 2.msi
C:\Junk\1.msi => C:\Junk\2.msi
     1 file copied

C:\Junk>copy 2.msi 3.msi
C:\Junk\2.msi => C:\Junk\3.msi
     1 file copied

C:\Junk>copy 3.msi 4.msi
C:\Junk\3.msi => C:\Junk\4.msi
     1 file copied

C:\Junk>copy 4.msi 5.msi
C:\Junk\4.msi => C:\Junk\5.msi
     1 file copied

C:\Junk>sha1sum Dataram_RAMDisk_V3.5.130R18.msi 1.msi 2.msi 3.msi 4.msi 5.msi
sha1sum: Dataram_RAMDisk_V3.5.130R18.msi: No such file or directory
d1941547c14dfa0fcfe073fb82763fc5e84a02c1 *1.msi
d1941547c14dfa0fcfe073fb82763fc5e84a02c1 *2.msi
d1941547c14dfa0fcfe073fb82763fc5e84a02c1 *3.msi
d1941547c14dfa0fcfe073fb82763fc5e84a02c1 *4.msi
d1941547c14dfa0fcfe073fb82763fc5e84a02c1 *5.msi

C:\Junk>ver

TCC  13.00.23 x64   Windows 7 [Version 6.1.7601]

C:\Junk>
 
Although I've often suspected that the "/V[erify]" flag was, how shall we say, bogus.)

Definitely not -- the /V does a byte-by-byte comparison. (However, it doesn't necessarily actually compare what's on the disk, as your disk and Windows will be cacheing. So it's theoretically possible that the data in your cache won't match what's on the disk, but that'll be a Windows / disk driver problem, not TCC.)
 
I've tried copying several different files, including other MSI files and I think there's something about that Dataram install file that TCC doesn't like.

It's not TCC, since TCC isn't doing the copy (Windows is, with the CopyFileEx API).

I cannot reproduce it here with Windows 7 and Dataram_RAMDisk_V3.5.130R19.msi. If I had to make a SWAG, I'd guess it might have something to do with (1) a .msi downloaded from the Internet, and therefore marked as unsafe by Windows (right click on the file and look at the Properties); (2) related somehow to the code signing on the file, and/or (3) an XP oddity.

I doubt it's a bug in the CopyFileEx API, as that would affect a couple billion people, not one or two. However, CMD uses the (older) CopyFile API instead, so there could be a difference in their output.

If COPY was aliased to /J, it would also affect the output.

The only important question is -- does the file still execute properly? If so, it has *not* been changed, regardless of the output of fc. (If it were, the code signing would cause the load to fail as the checksum wouldn't match.)
 
Just tried it with your R18 and XP (in a VM), and still cannot reproduce it.
I just did the same thing (XP in a VM running TCC from a stick) and was unable to reproduce the problem there. I also copied one of the "changed" copies to the VM, verified the SHA1 was still different than the original and it installed fine. My brain hurts now. I give up.
 
I can't reproduce it:

HTML:
C:\Junk>copy Dataram_RAMDisk_V3.5.130R18.msi 1.msi
C:\Junk\Dataram_RAMDisk_V3.5.130R18.msi => C:\Junk\1.msi
     1 file copied

C:\Junk>fc Dataram_RAMDisk_V3.5.130R18.msi 1.msi
Comparing files Dataram_RAMDisk_V3.5.130R18.msi and 1.MSI
FC: no differences encountered

C:\Junk>dir

 Volume in drive C is TI105444W0C    Serial number is 709c:de9d
 Directory of  C:\Junk\*

 9/19/2011   2:22p        <DIR>    .
 9/19/2011   2:22p        <DIR>    ..
 9/06/2011  10:10a      3,140,608  1.msi
 9/19/2011   2:19p      2,816,238  Dataram.zip
 9/06/2011  10:10a      3,140,608  Dataram_RAMDisk_V3.5.130R18.msi
         9,097,454 bytes in 3 files and 2 dirs    9,101,312 bytes allocated
   243,961,372,672 bytes free

C:\Junk> ver

TCC  13.00.23 x64   Windows 7 [Version 6.1.7601]

C:\Junk>
 
In Win7, if I right-click the file in Explorer
and chose Properties, then select the Details tab, there is an option at
the bottom to "Remove properties and personal information." If
I remove some or all of that information, the data at the following offsets
get modified (there is a lot more offsets than just these but these are
the ones that seem to be consistently reported):

0000046C: D0 70
0000046D: ED 48
0000046E: F3 AD
0000046F: BA 4E
00000470: 02 9A
00000471: 77 0B
00000478: 40 80
00000479: 99 A8

If I had to guess, I'd say those are
a date/time stamp. What does XP show for the Details tab of the different
files?

-Scott




[C:\DL\x]
10:45:57 $ fc /b 4.msi 5.msi
Comparing files 4.msi and 5.MSI
0000046C: 00 30
0000046D: 41 0B
0000046E: 4C 18
0000046F: 13 16
Notice how after the first copy, only four
bytes are changing, but always at the same offset and never the same changes.
If I copied the original MSI file to 5 different copies, then it would
have been like the first example with six bytes changing.

I have no clue what's happening, just showing that the problem can be duplicated.
I can zip up my copy of the MSI file and post it somewhere if you want
it for testing.
 
In Win7, if I right-click the file in Explorer
and chose Properties, then select the Details tab, there is an option at
the bottom to "Remove properties and personal information." If
I remove some or all of that information, the data at the following offsets
get modified (there is a lot more offsets than just these but these are
the ones that seem to be consistently reported):
.
.
.
I have no clue what's happening, just showing that the problem can be duplicated.
Awesome job of sleuthing.
 
I've tried copying several different files, including other MSI files and I think there's something about that Dataram install file that TCC doesn't like. I can't explain it though. Here's CMD. .... I have no clue what's happening, just showing that the problem can be duplicated. I can zip up my copy of the MSI file and post it somewhere if you want it for testing.

I'm not running any plugins or using an alias for copy.
John, I sincerely thank you for establishing that I am not crazy.... ; > ) >
 
Definitely not -- the /V does a byte-by-byte comparison. (However, it doesn't necessarily actually compare what's on the disk, as your disk and Windows will be cacheing. So it's theoretically possible that the data in your cache won't match what's on the disk, but that'll be a Windows / disk driver problem, not TCC.)
Rex, I have to ask: What is its point if it does not compare what is actually on disk???? I think that the probability of what's in RAM being incorrect is about as close to zero as one could get assuming that your system is still functioning at all, whereas the same is not quite as true when copying to what is essentially a mechanical device - i. e., a physical disk drive. If what you say is true (and I really don't doubt that) it establishes, to me, that the "/V" option is, in fact, bogus as I surmised.
 
> Rex, I have to ask: What is its point if it *does not* compare what is
> actually *on disk*????

It is not possible in Windows (or for that matter with any modern disk
drives) to force a comparison of what is physically on the disk platters.

But if what is in the disk RAM buffers and what is actually on the disk
platters is different, your system will be completely trashed anyway. So
it'd be pointless (and impossible) to run a program that compared them.
 
I recreated the test using the newest R19 file to make sure that wasn't an issue and duplicated it on my box also (not in the XP VM box though). I used the original and 4 copies.
If I had to guess, I'd say those are
a date/time stamp. What does XP show for the Details tab of the different
files?
That's my guess too now that I look at them. Looking at all the tabs in the Properties of the 5 files, the only difference I see are the File Modification Time.

Here are the "FC /b" differences grouped together in a table followed by the file times.
Code:
MSI file:  1  2  3  4  Original
0000046C: 40 E0 90 90 B0
0000046D: 89 A5 08 90 09
0000046E: 23 EE A6 2A 15
0000046F: 4D 51 55 58 C4
00000470: 08 08 08 08 5F
00000471: 77 77 77 77 62
Code:
[C:\DL\x]
15:52:20 $ pdir /(th:m:sd   f)
15:11:22.452   1.msi
15:11:30.494   2.msi
15:11:36.729   3.msi
15:11:40.953   4.msi
12:42:11.966   Dataram_RAMDisk_V3.5.130R19.msi
Hopefully this helps to troubleshoot.
 
I do not have a clue as to what is going on here, nor do I know how "important" it is given that I know that it exists and how to easily circumvent it, but the following is complete, precise, documentation of the situation at hand:
Folks, I'm completely willing to just let it go at that at this moment. That is both because that program I wrote that I mentioned in another posting will not let this happen without my knowledge (and, again, because of my paranoia, I use it 100% of the time for files that I consider to be important - more for my general incompetency due to my bad memory than anything else), and if it actually does ever happen again I, of course, know exactly how to easily circumvent it by using cmd.exe. And I really thank you, "Mr. Smith". for at least establishing that I am not crazy!!!! : > ) > With all of my other disabilities, I don't need that one too!!!! And, I will add, as an aside, that as I have mentioned before one of my other disabilities is poor eyesight. This leaves using the Windows GUI for most things pretty much impractical for me. While it is possible to increase font sizes for various parts of the GUI (although you really have to look to find out how to actually do it - it wasn't at all obvious, at least to me), doing so has the effect of effectively reducing the amount of space available for the various windows' contents to point where the various GUI windows essentially become close to useless, particularly since my screen "real-estate" is already somewhat limited by my need to use (and depend on) the native Windows "magnify" app). However, increasing the font size for TCC windows has very little negative consequences. So between that and the generally much-advanced "power" of Take Command/TCC (for instance, I use "Aliases" to start every single program I use "regularly" - "word" for Microsoft Word, "excel" for Microsoft Excel, "firefox" for FireFox (my "preferred web browser), etc., etc., etc.) means I almost never use the Windows GUI anything except for task-switching (Alt-Tab).

And, as I final note, my RAMDisk is installed and running fine; I no longer have any idea, whatsoever, whether I installed it from a "good" .msi file or a "corrupted" .msi file, and I really don't think it matters all that much at this point in time.
 
FWIW, offsets 472 and 473 always contain
CC and 01. So combining all 8 bytes in little endian order and calling
@AGEDATE yields:
echo %@agedate[%@eval[0x01CC77084D238940
]]
echo %@agedate[%@eval[0x01CC770851EEA5E0
]]
echo %@agedate[%@eval[0x01CC770855A60890
]]
echo %@agedate[%@eval[0x01CC7708582A9090
]]
echo %@agedate[%@eval[0x01CC625FC41509B0]]

2011-09-19,20:11:22.452
2011-09-19,20:11:30.494
2011-09-19,20:11:36.729
2011-09-19,20:11:40.953
2011-08-24,13:14:33.803

Which tells me it is in fact a date/time
stamp.

I don't know what the next 6 bytes mean
though. And I have even less of an idea as to why WinXP would be
modifying an OLE compound document when it is copied.

-Scott






I recreated the test using the newest R19
file to make sure that wasn't an issue and duplicated it on my box also
(not in the XP VM box though). I used the original and 4 copies.
Quote:


Originally Posted by samintz

If I had to guess, I'd say those are
a date/time stamp. What does XP show for the Details tab of the different
files?
That's my guess too now that I look at
them. Looking at all the tabs in the Properties of the 5 files, the only
difference I see are the File Modification Time.

Here are the "FC /b" differences grouped together in a table
followed by the file times.
Code:
MSI file: 1 2 3 4
Original
0000046C: 40 E0 90 90 B0
0000046D: 89 A5 08 90 09
0000046E: 23 EE A6 2A 15
0000046F: 4D 51 55 58 C4
00000470: 08 08 08 08 5F
00000471: 77 77 77 77 62
Code:
[C:\DL\x]
15:52:20 $ pdir /(th:m:sd f)
15:11:22.452 1.msi
15:11:30.494 2.msi
15:11:36.729 3.msi
15:11:40.953 4.msi
12:42:11.966 Dataram_RAMDisk_V3.5.130R19.msi
Hopefully this helps to troubleshoot.
 
FWIW, offsets 472 and 473 always contain
CC and 01. So combining all 8 bytes in little endian order and calling
@AGEDATE yields:
echo %@agedate[%@eval[0x01CC77084D238940
]]
echo %@agedate[%@eval[0x01CC770851EEA5E0
]]
echo %@agedate[%@eval[0x01CC770855A60890
]]
echo %@agedate[%@eval[0x01CC7708582A9090
]]
echo %@agedate[%@eval[0x01CC625FC41509B0]]

2011-09-19,20:11:22.452
2011-09-19,20:11:30.494
2011-09-19,20:11:36.729
2011-09-19,20:11:40.953
2011-08-24,13:14:33.803

Which tells me it is in fact a date/time
stamp.

I don't know what the next 6 bytes mean
though. And I have even less of an idea as to why WinXP would be
modifying an OLE compound document when it is copied.

-Scott

I recreated the test using the newest R19
file to make sure that wasn't an issue and duplicated it on my box also
(not in the XP VM box though). I used the original and 4 copies.
Quote:

Originally Posted by samintz

If I had to guess, I'd say those are a date/time stamp. What does XP show for the Details tab of the different files?

That's my guess too now that I look at them. Looking at all the tabs in the Properties of the 5 files, the only difference I see are the File Modification Time.

Here are the "FC /b" differences grouped together in a table
followed by the file times.
Code:
MSI file: 1 2 3 4
Original
0000046C: 40 E0 90 90 B0
0000046D: 89 A5 08 90 09
0000046E: 23 EE A6 2A 15
0000046F: 4D 51 55 58 C4
00000470: 08 08 08 08 5F
00000471: 77 77 77 77 62
Code:
[C:\DL\x]
15:52:20 $ pdir /(th:m:sd f)
15:11:22.452 1.msi
15:11:30.494 2.msi
15:11:36.729 3.msi
15:11:40.953 4.msi
12:42:11.966 Dataram_RAMDisk_V3.5.130R19.msi
Hopefully this helps to troubleshoot.
Wow, guys, I don't think you will mind when I say that I think you are absolutely brilliant!!!! I had no clue that Windows would or even could do something like that!!! Although, to be honest, I'm not completely sure I like it!!!! ; > ) >
 
I just became interested in this thread. I DL'd the file in question and copied it all over the place, both on XP and Win7. All copied were identical.

But I did notice something peculiar that no one has mentioned ... that the file has an attached stream.

Code:
z:\users\vefatica\desktop\dataram> dir /k /m /h /:
2011-09-19  19:44       3,141,120  1.msi
                               26    Zone.Identifier:$DATA
2011-09-19  19:44       3,141,120  2 - Copy.msi
                               26    Zone.Identifier:$DATA
2011-09-19  19:44       3,141,120  2.msi
                               26    Zone.Identifier:$DATA
2011-09-19  19:44       3,141,120  Dataram_RAMDisk_V3.5.130R19.msi
                               26    Zone.Identifier:$DATA
I'm curious as to what the stream is all about and whether (on some systems) it has anything to do with the peculiar observations.
 
And someone mentioned a possible connection with the file having come from the
internet. I looked in an archive I keep of DL'd things and very many of them
have such a stream, including stuff from JPSoft. And the few of these streams
I've looked at were all the same:

Code:
i:\jpsoft\beta13> dir /k /m /h /: /s
2011-09-13  02:11       9,884,216  tcmd.exe
                               26    Zone.Identifier:$DATA
2011-08-11  17:18       9,505,800  tcmd.zip

i:\jpsoft\beta13> type tcmd.exe:Zone.Identifier
[ZoneTransfer]
ZoneId=3

On Mon, 19 Sep 2011 22:11:25 -0400, vefatica <> wrote:

|I just became interested in this thread. I DL'd the file in question and copied it all over the place, both on XP and Win7. All copied were identical.
|
|But I did notice something peculiar that no one has mentioned ... that the file has an attached stream.
|
|
|Code:
|---------
|z:\users\vefatica\desktop\dataram> dir /k /m /h /:
|2011-09-19 19:44 3,141,120 1.msi
| 26 Zone.Identifier:$DATA
|2011-09-19 19:44 3,141,120 2 - Copy.msi
| 26 Zone.Identifier:$DATA
|2011-09-19 19:44 3,141,120 2.msi
| 26 Zone.Identifier:$DATA
|2011-09-19 19:44 3,141,120 Dataram_RAMDisk_V3.5.130R19.msi
| 26 Zone.Identifier:$DATA
|---------
|I'm curious as to what the stream is all about and whether (on some systems) it has anything to do with the peculiar observations.
 
What does the "Zone ID" option do in TCC? I've read the Help, but don't understand what "Set the NTFS Zone ID security when running executables downloaded from the Internet" means. Does this mean you get a warning when you try to run a file downloaded from certain zones?
 

Similar threads

Back
Top