1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

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

Discussion in 'Support' started by mathewsdw, Sep 18, 2011.

  1. mathewsdw

    Joined:
    May 24, 2010
    Messages:
    855
    Likes Received:
    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]
     
  2. FileViewer

    Joined:
    Aug 3, 2011
    Messages:
    37
    Likes Received:
    0
    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.
     
  3. Quatrix

    Joined:
    Dec 14, 2009
    Messages:
    8
    Likes Received:
    0
    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?
     
  4. FileViewer

    Joined:
    Aug 3, 2011
    Messages:
    37
    Likes Received:
    0
    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.
     
  5. Quatrix

    Joined:
    Dec 14, 2009
    Messages:
    8
    Likes Received:
    0
    Isn't VIEW new in version 13? I think he's on 12.
     
  6. mathewsdw

    Joined:
    May 24, 2010
    Messages:
    855
    Likes Received:
    0
    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).
     

    Attached Files:

  7. mathewsdw

    Joined:
    May 24, 2010
    Messages:
    855
    Likes Received:
    0
    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.
     
  8. Charles Dye

    Charles Dye Super Moderator
    Staff Member

    Joined:
    May 20, 2008
    Messages:
    3,372
    Likes Received:
    40
    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?
     
  9. JohnQSmith

    Joined:
    Jan 19, 2011
    Messages:
    559
    Likes Received:
    7
    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.
     
  10. David Marcus

    Joined:
    Jun 4, 2008
    Messages:
    649
    Likes Received:
    1
    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>
     
  11. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    10,090
    Likes Received:
    85
    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.)
     
  12. JohnQSmith

    Joined:
    Jan 19, 2011
    Messages:
    559
    Likes Received:
    7
    Here's R18 for a couple of days at least.
     
  13. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    10,090
    Likes Received:
    85
    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.)
     
  14. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    10,090
    Likes Received:
    85
    Also not reproducible with r18 & Windows 7.
     
  15. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    10,090
    Likes Received:
    85
    Just tried it with your R18 and XP (in a VM), and still cannot reproduce it.
     
  16. JohnQSmith

    Joined:
    Jan 19, 2011
    Messages:
    559
    Likes Received:
    7
    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.
     
  17. David Marcus

    Joined:
    Jun 4, 2008
    Messages:
    649
    Likes Received:
    1
    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>
     
  18. samintz

    samintz Scott Mintz

    Joined:
    May 20, 2008
    Messages:
    1,203
    Likes Received:
    11
    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.
     
  19. JohnQSmith

    Joined:
    Jan 19, 2011
    Messages:
    559
    Likes Received:
    7
    Awesome job of sleuthing.
     
  20. mathewsdw

    Joined:
    May 24, 2010
    Messages:
    855
    Likes Received:
    0
    John, I sincerely thank you for establishing that I am not crazy.... ; > ) >
     
  21. mathewsdw

    Joined:
    May 24, 2010
    Messages:
    855
    Likes Received:
    0
    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.
     
  22. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    10,090
    Likes Received:
    85
    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.
     
  23. JohnQSmith

    Joined:
    Jan 19, 2011
    Messages:
    559
    Likes Received:
    7
    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.
    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.
     
  24. mathewsdw

    Joined:
    May 24, 2010
    Messages:
    855
    Likes Received:
    0
    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.
     
  25. samintz

    samintz Scott Mintz

    Joined:
    May 20, 2008
    Messages:
    1,203
    Likes Received:
    11
    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.
     
    MaartenG likes this.
  26. mathewsdw

    Joined:
    May 24, 2010
    Messages:
    855
    Likes Received:
    0
    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!!!! ; > ) >
     
  27. vefatica

    Joined:
    May 20, 2008
    Messages:
    8,129
    Likes Received:
    33
    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.
     
  28. vefatica

    Joined:
    May 20, 2008
    Messages:
    8,129
    Likes Received:
    33
    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.
     
  29. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    10,090
    Likes Received:
    85
    See the help for "Zone ID" in OPTION / Startup.
     
  30. David Marcus

    Joined:
    Jun 4, 2008
    Messages:
    649
    Likes Received:
    1
    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?
     

Share This Page