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...

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....
Vince, I don't see how the fact that the file has attached "streams" (while interesting) can have anything to do with it. This is because my program and the native Windows "fc" program have absolutely no knowledge, from what I understand (I am certainly not an expert in this subject) that those "streams" even exist. Maybe I should look into it further because it implies that my program that deletes "duplicate" files could delete a file whose "primary" stream was identical to the "primary" stream of another file, but other streams could be different or even not exist at all, which would indicate that my program could delete a file it really shouldn't because it is not really "identical" to the "reference" file. (Although it's not a high likelihood for me because I simply do not "create" files with streams in the first place.)

I will also note that, if you read the other postings in this thread, another posting in this thread has identified the complete explanation for the file differences that I was seeing.
 
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
Vince, Since I had a few minutes to "waste", I thought I'd give the "/:" parameter a try (I wasn't familiar with it; but then again as I said I don't use streams), and I was very surprised by both what was there as well as what wasn't there!!!
 
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
Vince, since I had a few minutes to "waste", I thought I'd give the "/:" parameter a try (I wasn't familiar with it; but then again as I said I don't use streams), and I was very surprised by both what wasn't there as well as what was there!!! Specifically,
Code:
dir /k /m /:
produced:
HTML:
 9/18/2011  22:29         [DIR]    .
 9/18/2011  22:29         [DIR]    ..
                                0    BadRoot.txt:$DATA
                       16,474,125    NoParm.txt:$DATA
                       14,168,169    Parm.txt:$DATA
 9/18/2011  22:30         [DIR]    Test
 9/17/2011  23:53       3,141,120  Dataram_RAMDisk_V3.5.130R19.msi
which, for "Dataram_RAMDisk_V3.5.130R19.msi" (which is the file whose unexpected (to me) date/time stamp started this whole thread) shows no "stream" for "$DATA" or anything else for that matter (I thought from what little I knew about it that "$DATA" was pretty much a "standard" "stream" that every file had because it represented the contents of the file as seen by those programs that were totally unaware of "streams"; but apparently I was wrong), but even more weirdly, what are these "BadRoot.txt", "NoParm.txt", and "Parm.txt", which look suspiciously like files that I might have created (and then deleted), and even more strangely, one is more than 15MB long, and the other more than 13.5MB long! Not only that, if I add the parameter "/AD" to the "dir" command, they show up as directories ("directories" with non-zero sizes????) Then I did a little more experimentation: I made and CD'd into a directory ("MD XXX /D") on my D: drive (a "regular", physical hard-drive partition), did a "dir /:", and those same two files showed up. I deleted that directory, made and CD'd into a directory on my Z: drive (a RAMDisk), and those two files did not show up! (My "RAM" disk seems to appear as a "plain old" ordinary disk drive to every program/utility/whatever I've ever tried on it, including deleted-file "recovery" programs.) Even though this is "addressed" to Vince because he "opened" the subject, if any one else out there can tell me what is going on here I would be glad to hear it!
 
I will also note that, if you read the other postings in this thread, another posting in this thread has identified the complete explanation for the file differences that I was seeing.

I must have missed that. What is the explanation? While it has been suggested that the changed bytes are a date-time stamp. No one seems to know why a file would be changing in that way. And, only two people are seeing the change. No one else sees it when they try it.
 
(I thought from what little I knew about it that $DATA was pretty much a standard stream that every file had because it represented the contents of the file as seen by those programs that were totally unaware of streams; but apparently I was wrong) [quotes and bold removed]

See

http://msdn.microsoft.com/en-us/library/aa364404.aspx

The default data stream is unnamed. But, $DATA can also be the stream type. And, Windows (or the browser?) seems to put the zone ID in a stream named "$DATA" when you download files.

I'm not sure, but your dir listing looks like it is showing $DATA streams for files that don't have a default data stream. Is that possible?
 
If you download the program Procmon from
SysInternals you can monitor every little nuance of activity that happens
when you run an application. It boggles the mind how much "stuff"
happens under the covers now-a-days. There are a bazillion registry
checks, the whole WinSxS thing, virtualized redirection, etc.

No longer is the application loader
simply put this application at 100h and set the PC to that address.

-Scott

mathewsdw <> wrote on 09/20/2011
12:22:03 AM:


> Quote:
>
> Originally Posted by vefatica [image removed]
> 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....
>
> Vince, I don't see how the fact that the file has attached "streams"
> (while interesting) can have anything to do with it. This is because
my

> program and the native Windows "fc" program have absolutely
no

> knowledge, from what I understand (I am certainly not an expert in


> this subject) that those "streams" even exist. Maybe I should
look

> into it further because it implies that my program that deletes
> "duplicate" files could delete a file whose "primary"
stream was

> identical to the "primary" stream of another file, but other
streamscould be

> different or even not exist at all, which would indicate that my
> program could delete a file it really shouldn't because it is not
really

> "identical" to the "reference" file. (Although
it's not a high

> likelihood for me because I simply do not "create" files
with

> streams in the first place.)
>
> I will also note that, if you read the other postings in this
> thread, another posting in this thread has identified the complete


> explanation for the file differences that I was seeing.
>
>
 
I must have missed that. What is the explanation? While it has been suggested that the changed bytes are a date-time stamp. No one seems to know why a file would be changing in that way. And, only two people are seeing the change. No one else sees it when they try it.
Dave, you are correct, and I find this quite odd myself, that not everybody with Windows 7 experiences the byte-changes that I experienced when copying this particular file (although several other people have) and it is absolutely, 100% consistent that it changes those bytes whenever I do, in fact, copy that file with TCC and not cmd.exe. And Rex himself has stated himself in this thread that he uses a different (and, I believe, newer) Windows API function to copy a file than does the "copy" command in cmd.exe). However, that said, the people (there were two people involved) who made this discovery were able to prove, beyond the slightest shadow of a doubt (because they were able to take the series of "changed" bytes and run them through some function(s) available in TCC and produce a completely valid (as of approximately "now") date/time sequence), that that was what was going on. Unfortunately, as you can see, this thread has gotten quite long, and I can no longer remember exactly who it was who made the posting to "point" you at it verifying that this is, in fact, the case. I'm sorry for that.
 
However, that said, the people (there were two people involved) who made this discovery were able to prove, beyond the slightest shadow of a doubt (because they were able to take the series of changed bytes and run them through some function(s) available in TCC and produce a completely valid (as of approximately now) date/time sequence), that that was what was going on.

Only JohnQSmith was able to reproduce it on one system. Not sure what operating system he used. He couldn't reproduce it using XP in a VM.

The fact that the bytes appear to be date-times is interesting, but doesn't prove that Windows is the culprit or explain why the bytes are being changed.

By the way, people are more likely to read your posts if you refrain from the bold and quotes.
 
A personal response to David Marcus...

By the way, people are more likely to read your posts if you refrain from the bold and quotes.
Dave, out of respect for you I will try very hard to not use bold, quotes, italics and even possibly multiply-nested parenthetical expressions in this posting, but that will be as far as I can go, because it is, in fact, as I am finding out in even making this posting - very hard for me to do. The simple fact is that that is the way I write, period, and not just in this context. And many of my long time friends - the shortest of my many significant friendships being more than 26 years old - tell me that I write the way I talk and talk the way I write, or to put it another way, that is the way I think. I am truly sorry if that offends you in some way, the best I can suggest is if it bothers you that much just don't read them, I won't know and therefore won't be offended. And, given my very real bad memory, I probably wouldn't remember to avoid it even if that was my intent, which it is not, because, again, that is simply the way I write (and speak).
 

Similar threads

Back
Top