Msvcrt.dll v6.0.9782.0. help
astral
philo
MyNews
it a Msvcrt.dll is the Microsoft Visual C++ Run-Time for Visual C++ versions
4.2 to 6.0.
http://en.wikipedia.org/wiki/Visual_Studio
"philo" <ph...@privacy.net> wrote in message
news:idh8n7$qok$1...@news.eternal-september.org...
astral
"MyNews" <myn...@comcast.net> wrote in message
news:idhhkm$vr3$1...@speranza.aioe.org...
I replaced existing Msvcrt.dll with Msvcrt.dll 6.0.9782.0 which recommended
by m$ as last version for Win 98, but this not help me prevent periodically
terminating Firefox, periodically fault occurs and terminate Firefox.
PCR
What is the precise wording of your error message & your version of
FireFox? I don't have FireFox installed. My own, fully updated Win98
with a fully updated IE6 SP1 seems to have...
MSVCRT.DLL
Desc: Microsoft (R) C Runtime Library
Loc: C:\WINDOWS\SYSTEM
Size: 278,581 bytes
Mod: Thursday, April 06, 2000 08:10:40 PM
Ver: 6.00.8797.0
And I'm sure that came in with the IE6 cummulative updates. A Google
search comes up with over 44,000 hits for "firefox msvcrt.dll error"...
http://www.google.com/
You should read through a goodly bunch before doing much, but this one
is interesting...
http://icrontic.com/forum/showthread.php?t=35890
===Quote cyberrat=======
just wanted to let you know what i had to finally had to do to solve
this just in case it happens to anyone else i was using firefox for a
browser and the profile had been corrupted and all i had to do was
create a new profile and move my bookmarks to it installing the dll
actually did nothing to stop it
thank for all the help trying to help me trouble shoot this problem
nnice to know there are helpful people like you all around the net
===EOQ===============
--
Thanks or Good Luck,
There may be humor in this post, and,
Naturally, you will not sue,
Should things get worse after this,
PCR
pcr...@netzero.net
MyNews
I at Windows Update going to download Microsoft .NET Framework version 1.1
I'll do a Search for Msvcrt.dll to see if it come with it!
MyNews
I believe I may miss this one, that it may IE6 sp1
But Came with Install of Microsoft .NET Framework version 1.1
C:\windows\system32\Msvcrt.dll File Version 6.10.9844.0
C:\windows\system32\dllcache\Msvcrt.dll File Version 6.10.9844.0
"MyNews" <myn...@comcast.net> wrote in message
news:idkbed$90d$1...@speranza.aioe.org...
Sjouke Burry
wrote:http://web.archive.org/web/20060411175139/http://www.forteinc.com/agent/features.php
> I did all the updates for IE6 sp1 and Msvcrt.dll did not came with it..
> I at Windows Update going to download Microsoft .NET Framework version 1.1
> I'll do a Search for Msvcrt.dll to see if it come with it!
A file search at my xp machine came up with about 13 dll's.
3 of them older then the one you want,
one in graphics workshop, 6.0.8168.0,
in java/jre6/bin, 6.0.8337.0,
and macromedia player 5.0.0.7128.
So you might look around on some computers and find some to
experiment.
MyNews
"Sjouke Burry" <burrynu...@ppllaanneett.nnll> wrote in message
news:4cfdb717$0$8918$703f...@textnews.kpn.nl...
astral
Firefox crashes when I going into a some page containing flash I belive.
With MS Explorer nothing happens but Mozilla Firefox 2.0.0.20 crashes.
I belive this link about this issue:
http://support.microsoft.com/kb/895959/
I replaced with recommended Msvcrt.dll v6.0.9782.0., but this not help.
PCR
> Ok in C:\windows\Msvcrt.dll File Version 6.00.8397.0
> I believe I may miss this one, that it may IE6 sp1
That's the version of Msvcrt.dll (6.00.8397.0) that comes with Win98...
Cabinet WIN98_63.CAB
04-23-1999 10:22:00p A--- 266,293 msvcrt.dll
And both IE5.5 & IE6 come with the same version & size of the file in
SetUpW95.cab, but each has a different date. (I extracted all 3 just to
see.) My current version (as I posted elsewhere) is...
MSVCRT.DLL
Desc: Microsoft (R) C Runtime Library
Loc: C:\WINDOWS\SYSTEM
Size: 278,581 bytes
Mod: Thursday, April 06, 2000 08:10:40 PM
Ver: 6.00.8797.0
...,but I'm unsure where that came from. It doesn't appear to be in the
cummulative updates after all. I guess I might have separately updated
the C Runtime Library.
The file belongs in C:\Windows\System. Normally, just the Windows folder
(where you've got one) is good enough. HOWEVER, I guess it's worth a try
for you to move it to \System. Try each of these versions, if you've got
them...
6.00.8397.0 (Came with Win98 & both IE5.5 & IE6)
6.00.8797.0 (My current version - but where did I get it?)
6.00.9782.0 (Mentioned in that URL astral posted)
> But Came with Install of Microsoft .NET Framework version 1.1
> C:\windows\system32\Msvcrt.dll File Version 6.10.9844.0
> C:\windows\system32\dllcache\Msvcrt.dll File Version 6.10.9844.0
That's a 3rd folder altogether. Best leave it there, if that's where it
went. It may be meant only for the Framework's use.
But look again at my first post where I quoted cyberrat!
> "MyNews" <myn...@comcast.net> wrote in message
> news:idkbed$90d$1...@speranza.aioe.org...
>> I did all the updates for IE6 sp1 and Msvcrt.dll did not came with
>> it..
>> I at Windows Update going to download Microsoft .NET Framework
>> version 1.1 I'll do a Search for Msvcrt.dll to see if it come with
>> it!
--
MyNews
and will not crashes.
There will be one Warning that says
The system library Msimg32.dll is missing or too old, so certain
Transparency effects will be slow
and possibly not drawn correcting. obtaining the library from a Windows ME
installation
and placing it in your Windows system directory will fix this.
it's needed with Win98
just check the box
Do not show this dialog again.
And check Close
"astral" <ast...@news.eternal-september.org> wrote in message
news:idm84m$idr$1...@news.eternal-september.org...
legg
wrote:
>Ok in C:\windows\Msvcrt.dll File Version 6.00.8397.0
>I believe I may miss this one, that it may IE6 sp1
>
>But Came with Install of Microsoft .NET Framework version 1.1
>C:\windows\system32\Msvcrt.dll File Version 6.10.9844.0
>C:\windows\system32\dllcache\Msvcrt.dll File Version 6.10.9844.0
>
On this machine, msvcrt.dll is located in W98 C:\windows\system , not
*\system32. It will have it's own version. On this machine it's v
6.1.8924.0 from Jan2004 ~284K in size.
Perhaps you simply 'relocated' your file incorrectly, or recieved the
wrong instructions. It seems independant of java version in this
position.
(In W2K it shows up in C:\WINNT\SYSTEM32 v 6.1.9844.0 from Jun2003)
.
A file with the same name does show up in java installations, which
are upgraded with JRE 'runtime' packages, in the *\bin folder of the
java installation. This should probably be V6.0.8337.0, 600k in size
from around oct2000, in all JREs up to and including JRE6v11. The
Firefox portion of the Mozilla-ish Seamonkey does often require a JRE
update, on installation.
RL
legg
wrote:
>Ok in C:\windows\Msvcrt.dll File Version 6.00.8397.0
>I believe I may miss this one, that it may IE6 sp1
>
>But Came with Install of Microsoft .NET Framework version 1.1
>C:\windows\system32\Msvcrt.dll File Version 6.10.9844.0
>C:\windows\system32\dllcache\Msvcrt.dll File Version 6.10.9844.0
That W98 system version of msvcrt.dll was placed in this machine for a
Nero update.
RL
legg
wrote:
>Ok in C:\windows\Msvcrt.dll File Version 6.00.8397.0
>I believe I may miss this one, that it may IE6 sp1
>
>But Came with Install of Microsoft .NET Framework version 1.1
>C:\windows\system32\Msvcrt.dll File Version 6.10.9844.0
>C:\windows\system32\dllcache\Msvcrt.dll File Version 6.10.9844.0
I checked the records and this W98 machine also had the .NET Framework
version 1.1 installed, without the directory errors indicated above
for msvcrt.dll placement.
There's no dllcache folder on this W98 machine. It does show up in the
system32 folder of a W2K installation, though.
RL
MyNews
Only upudates for IE6 sp1
If I do a update now it will be for Microsoft .NET Framework version 1.1
only!
One at a time on Software and Updates the right way of do it would you say!
I’ll will go Opera first and start my Put-in updates like java!
Using Opera's revolutionary email client: http://www.opera.com/mail/
MyNews
98 se.
Whin i update in time to Windows Media Player 9 series*
it come with 120 new features and including Nero!
Now i just install DirectX 9 and it update (KB904706)
Msvcrt.dll File Version 6.00.8397.0 is the same!
Now time for Windows Media Player 9!
MyNews
the Player for
Adode Flash Player signed on 10/21/10 9:04 PM
i chick Yes there a new working Flash
C:\windows\Msvcrt.dll File Version 6.00.8397.0 the same!
and the burner was a Roxio CD Burning Applet for Windows Media Player!
legg
>On Tue, 07 Dec 2010 22:40:57 -0600, legg <le...@nospam.magma.ca> wrote:
>
>> On Mon, 6 Dec 2010 22:20:56 -0600, "MyNews" <myn...@comcast.net>
>> wrote:
>>
>>> Ok in C:\windows\Msvcrt.dll File Version 6.00.8397.0
>>> I believe I may miss this one, that it may IE6 sp1
>>>
>>> But Came with Install of Microsoft .NET Framework version 1.1
>>> C:\windows\system32\Msvcrt.dll File Version 6.10.9844.0
>>> C:\windows\system32\dllcache\Msvcrt.dll File Version 6.10.9844.0
>>
>> On this machine, msvcrt.dll is located in W98 C:\windows\system , not
>> *\system32. It will have it's own version. On this machine it's v
>> 6.1.8924.0 from Jan2004 ~284K in size.
>>
>> That W98 system version of msvcrt.dll was placed in this machine for a
>> Nero update.
>>
>> Perhaps you simply 'relocated' your file incorrectly, or recieved the
>> wrong instructions. It seems independant of java version in this
>> position.
>>
>> (In W2K it shows up in C:\WINNT\SYSTEM32 v 6.1.9844.0 from Jun2003)
>> .
>> A file with the same name does show up in java installations, which
>> are upgraded with JRE 'runtime' packages, in the *\bin folder of the
>> java installation. This should probably be V6.0.8337.0, 600k in size
>> from around oct2000, in all JREs up to and including JRE6v11. The
>> Firefox portion of the Mozilla-ish Seamonkey does often require a JRE
>> update, on installation.
>>
>> I checked the records and this W98 machine also had the .NET Framework
>> version 1.1 installed, without the directory errors indicated above
>> for msvcrt.dll placement.
>>
>> There's no dllcache folder on this W98 machine. It does show up in the
>> system32 folder of a W2K installation, though.
>>
>It's a New Install of Windows 98
>Only upudates for IE6 sp1
>If I do a update now it will be for Microsoft .NET Framework version 1.1
>only!
>One at a time on Software and Updates the right way of do it would you say!
>
>I’ll will go Opera first and start my Put-in updates like java!
>
>Windows Media Player 9 is install my First pug-in pop-up at the strat fo
>the Player for Adode Flash Player signed on 10/21/10 9:04 PM
>i chick Yes there a new working Flash
>C:\windows\Msvcrt.dll File Version 6.00.8397.0 the same!
>
>and the burner was a Roxio CD Burning Applet for Windows Media Player!
>
>Look i have Windows Media Player Ver. 6.4.07.1121 that come with Windows
>98 se.
>Whin i update in time to Windows Media Player 9 series*
>it come with 120 new features and including Nero!
>
>
>Now i just install DirectX 9 and it update (KB904706)
>Msvcrt.dll File Version 6.00.8397.0 is the same!
>
>Now time for Windows Media Player 9!
>
If you are looking for approximate age of the .dll version, look at
the 'modified' date. The 'created' date only indicates when it was
installed in the machine.
What region/language is your W98 machine's environment set for?
Perhaps this may affect the .dll version employed by the various
programs?
Different versions of the .dll will show up in different locations for
differing programs. Pay attention to correct directory location and
associated program, when making manual changes.
I thought that your issue was with the functioning of Firefox.
It sounds like you've obtained the .dll version that you were
originally looking for. Do you still have your original problem?
RL
astral
FIREFOX caused an invalid page fault in
module MSVCRT.DLL at 0167:7800d6f3.
Registers:
EAX=00000066 CS=0167 EIP=7800d6f3 EFLGS=00010216
EBX=00001521 SS=016f ESP=00d9d8d4 EBP=00d9d8dc
ECX=000003a4 DS=016f ESI=05264fff FS=3b8f
EDX=00000003 ES=016f EDI=0526f0b0 GS=0000
Bytes at CS:EIP:
f3 a5 ff 24 95 88 d7 00 78 23 d1 8a 06 88 07 46
Stack dump:
0526ea22 00001522 00d9d9c8 6010532c 0526ea22 05264971 00001521 00d9d9e8
023f1870 023d8f54 601052e1 00d9d9e8 05264971 00001521 05264971 60105e6c
The only thing that Firefox has some great add-ons like Firebug, Opera can
only wotk with some cutted vers of Firebug.
"MyNews" <myn...@comcast.net> wrote in message
news:idmv2d$nmh$1...@speranza.aioe.org...
Bill in Co
I think the created date indicates when the file was initially created - NOT
when it was installed. The modified date indicates the latest revision
date (for the particular version on his machine).
MyNews
MyNews
Etal
> "MyNews" wrote:
>
>> it not a Windows 98 Dll file
>> it a Msvcrt.dll is the Microsoft Visual C++ Run-Time for Visual C++
>> versions
>> 4.2 to 6.0.
>> http://en.wikipedia.org/wiki/Visual_Studio
>>
>>
>> "philo" wrote:
>>
>>> astral wrote:
>>>
>>>> Msvcrt.dll v6.0.9782.0.
>>>
>>> maybe here ?
>>>
>>> http://www.dll-files.com/
> -------
>
> I replaced existing Msvcrt.dll with Msvcrt.dll 6.0.9782.0
> which recommended by m$ as last version for Win 98, but this
> not help me prevent periodically terminating Firefox,
> periodically fault occurs and terminate Firefox.
>
I have no idea if i will help or not with your Flash-movies
crashing Firefox, but it shouldn't hurt to download and then run
the following update-installer:
<http://www.mdgx.com/files/VS6SP6U.EXE>
It has /some/ "Visual Studio 6 Service Pack 6 Update" (VS6 SP6
Update) - Run-Time related files.
My copy of that from years ago contain the file and version you
asked for (and my notes also say it is the last version for
Windows), but i just DL'ed the file at that URL again and
strangely the present copy now lacks that particular file!
My thinking to why do it anyway is that it will install many of
the related Visual Studio C Runtime files, and it will re-write
registry entries. It you now have replaced the [msVCRt.dll] file
doing also the associated files just might correct something.
Shouldn't hurt.
But from what i gather; getting to play newer versions of online
Flash-movies inside a web-browser is getting harder and harder
under Win98.
--
MyNews
"Etal" <http://www.mdgx.com/files/VS6SP6U.EXE>
Visual Studio 6 Service Pack 6 Update" (VS6 SP6
Update) is for XP
Windows 2000 Msvcrt.dll is 6.10.9844.0 Microsoft ® Visual C++ 1981-1999
Windows ME Msvcrt.dll is 6.10.8637.0 Microsoft ® Visual C++ 1981-1999
Windows 98 Msvcrt.dll is 6.00.8397.0 Microsoft ® Visual C++ 1981-1998
now the Win ME will work on 98
legg
<surly_cu...@earthlink.net> wrote:
>legg wrote:
>> On Tue, 07 Dec 2010 23:18:15 -0600, MyNews <myn...@comcast.com> wrote:
>>
<snip>
>> If you are looking for approximate age of the .dll version, look at
>> the 'modified' date. The 'created' date only indicates when it was
>> installed in the machine.
>
>I think the created date indicates when the file was initially created - NOT
>when it was installed. The modified date indicates the latest revision
>date (for the particular version on his machine).
>
You'd think so, wouldn't you. In fact the create date is the date the
file/rev is placed on the disc. Bugs me too - a modify date preceding
a creation date. Effing SW guys missed some basics in their own
creation or were inadequately modified along the way.
It's just a symptom of the disease.....
RL
legg
wrote:
>>I thought that your issue was with the functioning of Firefox.
>> It sounds like you've obtained the .dll version that you were
>> originally looking for. Do you still have your original problem?
>The version of your Firefox is?
I think I mentioned that I'm using the Seamonkey package, of which the
browser component is what is typically distributed as Firefox.
Seamonkey includes the venerable Netscape composer, for web page
composition.
The install rev of the SM package was 1.1.9.
You'll make things a lot easier for all involved, if you answer
questions. It's not easy to maintain some kind of continuity in the
troubleshooting process.
RL
FromTheRafters
> On Wed, 8 Dec 2010 14:54:06 -0700, "Bill in Co"
> <surly_cu...@earthlink.net> wrote:
>
>> legg wrote:
>>> On Tue, 07 Dec 2010 23:18:15 -0600, MyNews<myn...@comcast.com> wrote:
>>>
> <snip>
>>> If you are looking for approximate age of the .dll version, look at
>>> the 'modified' date. The 'created' date only indicates when it was
>>> installed in the machine.
>>
>> I think the created date indicates when the file was initially created - NOT
>> when it was installed. The modified date indicates the latest revision
>> date (for the particular version on his machine).
>>
> You'd think so, wouldn't you. In fact the create date is the date the
> file/rev is placed on the disc.
Technically, it (the file) isn't placed on the disk. The terminology is
actually good. The *file* is "created" on the disk and the content of
the remote file (the program, document, or whatever) is transferred to
that newly created file. There is sometimes a way to retain the source's
'file creation date' with some protocols - the just modify the creation
date to match the source.
The "program" creation date might be inside the resource section - the
date it was compiled.
[...]
MyNews
Visual C++ 2005 (known also as Visual C++ 8.0), which included MFC 8.0, was
released in November 2005. This version supports .NET 2.0 and dropped
Managed C++ for C++/CLI. Managed C++ for CLI is still available via compiler
options though. It also introduced OpenMP. With Visual C++ 2005, Microsoft
also introduced Team Foundation Server. Visual C++ 8.0 has problems
compiling MFC AppWizard projects that were created using Visual Studio 6.0,
so maintenance of legacy projects can be continued with the original IDE if
rewriting was not feasible. Visual C++ 2005 is the last version to be able
to target Windows 98, Windows Me and Windows NT 4.0. [18] [19]
That’s all!
MyNews
PCR
> Here is error code:
>
> FIREFOX caused an invalid page fault in
> module MSVCRT.DLL at 0167:7800d6f3.
> Registers:
> EAX=00000066 CS=0167 EIP=7800d6f3 EFLGS=00010216
> EBX=00001521 SS=016f ESP=00d9d8d4 EBP=00d9d8dc
> ECX=000003a4 DS=016f ESI=05264fff FS=3b8f
> EDX=00000003 ES=016f EDI=0526f0b0 GS=0000
> Bytes at CS:EIP:
> f3 a5 ff 24 95 88 d7 00 78 23 d1 8a 06 88 07 46
> Stack dump:
> 0526ea22 00001522 00d9d9c8 6010532c 0526ea22 05264971 00001521
> 00d9d9e8 023f1870 023d8f54 601052e1 00d9d9e8 05264971 00001521
> 05264971 60105e6c
>
>
> The only thing that Firefox has some great add-ons like Firebug,
> Opera can only wotk with some cutted vers of Firebug.
>
http://www.google.com/search?hl=en&source=hp&q=firefox+invalid+page+fault+msvcrt.dll
Google has about 1040 hits for "firefox invalid page fault msvcrt.dll".
Read through a bunch & get back to us with a plan.
--
Etal
> legg wrote:
>
>> "Bill in Co" wrote:
>>
>>> legg wrote:
>>>
>> <snip>
>>>> If you are looking for approximate age of the .dll
>>>> version, look at the 'modified' date. The 'created' date
>>>> only indicates when it was installed in the machine.
>>>
>>> I think the created date indicates when the file was
>>> initially created - NOT when it was installed. The
>>> modified date indicates the latest revision date (for the
>>> particular version on his machine).
>>>
>> You'd think so, wouldn't you. In fact the create date is the
>> date the file/rev is placed on the disc.
>
> Technically, it (the file) isn't placed on the disk. The
> terminology is actually good. The *file* is "created" on the
> disk and the content of the remote file (the program,
> document, or whatever) is transferred to that newly created
> file. There is sometimes a way to retain the source's 'file
> creation date' with some protocols - the just modify the
> creation date to match the source.
The terminology used is actually insufficient. It doesn't (allow
to) differentiate between the creation-date of a file and the
creation-date of an _instance_ of a file.
When it comes to digital files, what is the difference between a
copy of the original and that of the original copy? .. i mean
except for the different creation dates of the file-instances.
>
> The "program" creation date might be inside the resource
> section - the date it was compiled.
>
> [...]
--
"I ain't different from anyone
It ain't no use talking to me
It's just the same as talking to you."
MyNews
•Windows Vista
•Windows XP
•Windows Me
•Windows 2000
•Windows 98
64-Bit Versions
•Windows Vista x64
•Windows XP x64
Download Firefox 2.0.0.20 (5.77 MB)
http://www.oldapps.com/firefox.php?old_firefox=7?download
The list Firefox for Windows 98
+++++++++++++++++=
System Requirements of Firefox 332-Bit versions
•Windows Vista
•Windows XP
•Windows 2000
64-Bit Versions
•Windows Vista x64
•Windows XP x64
See not for Windows 98
"MyNews" <myn...@comcast.net> wrote in message
news:idrn6n$ai7$1...@speranza.aioe.org...
MyNews
Makes that FIREFOX look like a childs toy!
Etal
>
> "Etal" <http://www.mdgx.com/files/VS6SP6U.EXE>
>
> Visual Studio 6 Service Pack 6 Update" (VS6 SP6
> Update) is for XP
Perhaps the SP6 as issued by ms, but the above referenced file is
not exactly that but actually an installer modded to install the
latest versions that will work with Win98 onto Win98. It has been
updated and contain files from as recently as (2009-03-24).
>
> Windows 2000 Msvcrt.dll is 6.10.9844.0 Microsoft ® Visual C++ 1981-1999
>
> Windows ME Msvcrt.dll is 6.10.8637.0 Microsoft ® Visual C++ 1981-1999
>
> Windows 98 Msvcrt.dll is 6.00.8397.0 Microsoft ® Visual C++ 1981-1998
>
> now the Win ME will work on 98
>
I'm not sure what you mean by "is" .. but if you mean "the latest
version for ... is" you are wrong about Win98 since ms has
[msVCRt.dll] 6.00.8797.0000(2000-03-07) inside the
(2000-11-15) Visual Studio 6.00.8797.0 Run-time Redist (Q259403)
for OS-versions including Win98.
<http://support.microsoft.com/kb/259403/>
--
MyNews
Put it between Windows 2000 and Windows ME
Ver. 6.00.8798.0
1981-1998
But it do up data it!
Good Info Etal ;)
Windows 2000 Msvcrt.dll is 6.10.9844.0 Microsoft ® Visual C++ 1981-1999
Windows ME Msvcrt.dll is 6.10.8637.0 Microsoft ® Visual C++ 1981-1999
Windows 98 Msvcrt.dll is 6.00.8397.0 Microsoft ® Visual C++ 1981-1998
>
Bill in Co
I'm still assuming it's the date the file was compiled: the compiled date
stamp. Subsequent *identical* copies of it (and their new dates (if any)
would seem to be of little use, as long as the code was identical to when it
was first compiled.
For example, if some DLL file has a creation date of 12/2004, then who cares
about the dates of any newer copies *so long as the file contains the
originally compiled code of 12/2004* - meaning no changes or revisions were
made to it.
FromTheRafters
The "file" doesn't matter. The file is created by the filesystem, *not*
the programmer. The programmer created the content that was stored in
the file. It's like throwing out all of your cookies because the the
cookie jar your grandmother gave you is so old.
> When it comes to digital files, what is the difference between a copy of
> the original and that of the original copy? .. i mean except for the
> different creation dates of the file-instances.
No difference, and that is the point. You put your cookies in a new jar,
and they are still the same old cookies. Creation date and modification
date are filesystem artifacts - compile date (for executables) tells you
when the author compiled the program - it is not a filesystem thing.
Etal
> Etal wrote:
>
>> The terminology used is actually insufficient. It doesn't
>> (allow to) differentiate between the creation-date of a file
>> and the creation-date of an _instance_ of a file.
>>
>> When it comes to digital files, what is the difference
>> between a copy of the original and that of the original
>> copy? .. i mean except for the different creation dates of
>> the file-instances.
>
> I'm still assuming it's the date the file was compiled: the
> compiled date stamp. Subsequent *identical* copies of it
> (and their new dates (if any) would seem to be of little use,
> as long as the code was identical to when it was first
> compiled.
Look at the majority of files in %WinDir%\System\, the ones that
have a modification-date of 1998-1999 of the original Win98xE.
The files were obviously created/compiled at that date or
earlier, but on your machine they will have the creation-date of
what your computers clock were set at when you installed windows.
IOW, the creation-dates of that particular instance of the files.
>
> For example, if some DLL file has a creation date of 12/2004,
> then who cares about the dates of any newer copies *so long as
> the file contains the originally compiled code of 12/2004* -
> meaning no changes or revisions were made to it.
>
It seems that the people that creates the file-systems,
operating-system, copy-routines and file-transfer protocols
thinks that the creation-date of a particular instance of a file
that is what is important (for the most part).
Me, i'd like there to be provisions to see two (different)
creation-dates for each file.
--
Etal
> Etal wrote:
>
>> FromTheRafters wrote:
>>
>>> legg wrote:
>>>
>>>> You'd think so, wouldn't you. In fact the create date is
>>>> the date the file/rev is placed on the disc.
>>>
>>> Technically, it (the file) isn't placed on the disk. The
>>> terminology is actually good. The *file* is "created" on
>>> the disk and the content of the remote file (the program,
>>> document, or whatever) is transferred to that newly
>>> created file. There is sometimes a way to retain the
>>> source's 'file creation date' with some protocols - the
>>> just modify the creation date to match the source.
>>
>> The terminology used is actually insufficient. It doesn't
>> (allow to) differentiate between the creation-date of a file
>> and the creation-date of an _instance_ of a file.
>
> The "file" doesn't matter. The file is created by the
> filesystem, *not* the programmer. The programmer created the
> content that was stored in the file. It's like throwing out
> all of your cookies because the the cookie jar your
> grandmother gave you is so old.
Whether you look at it as the container or as the content doesn't
matter. The fact is that the creation-date shown when you look at
a files property in Windows it is the creation-date of that
instance of the container/content.
>
>> When it comes to digital files, what is the difference
>> between a copy of the original and that of the original
>> copy? .. i mean except for the different creation dates of
>> the file-instances.
>
> No difference, and that is the point. You put your cookies in
> a new jar, and they are still the same old cookies. Creation
> date and modification date are filesystem artifacts - compile
> date (for executables) tells you when the author compiled the
> program - it is not a filesystem thing.
>
Yes, just like you wrote in a previous post:
>>> The "program" creation date might be inside the resource
>>> section - the date it was compiled.
>>>
This is something you can find out for files of a select few
file-types, but not for the vast majority of files of different
kinds. Look at Bill-in-Co's followup to my post and see which one
he thinks it is important to know and assumes that it is that is
show as the creation-date for any file.
So to be able to know that date for all files, that's why i said
that the terminology (and the reality of a property-page) ought
to provide for two creation-dates to be given for each file; one
instance-dependent that differs for each particular instance
(like you see today), and one constant instance-oblivious
creation-date for the original creation (of the
container/content). And no, the latter is not the same thing as
the modification date.
--
Bill in Co
> Bill in Co wrote:
>
>> Etal wrote:
>>
>
>>> The terminology used is actually insufficient. It doesn't
>>> (allow to) differentiate between the creation-date of a file
>>> and the creation-date of an _instance_ of a file.
>>>
>>> When it comes to digital files, what is the difference
>>> between a copy of the original and that of the original
>>> copy? .. i mean except for the different creation dates of
>>> the file-instances.
>>
>> I'm still assuming it's the date the file was compiled: the
>> compiled date stamp. Subsequent *identical* copies of it
>> (and their new dates (if any) would seem to be of little use,
>> as long as the code was identical to when it was first
>> compiled.
>
> Look at the majority of files in %WinDir%\System\, the ones that
> have a modification-date of 1998-1999 of the original Win98xE.
Good point - let's go with that...
> The files were obviously created/compiled at that date or
> earlier, but on your machine they will have the creation-date of
> what your computers clock were set at when you installed windows.
Huh? I don't think so. I think the date stamp is irrelevant of when it
was installed on my system. I mean, you just made the point - I've got
lots of really old files (like DLLs and EXEs) that have dates preceding my
computer ever being here!.
For example, a bunch of them are dated 8/4/2004, which has nothing to do
with when it was installed on my computer. And the creation and
modification dates are almost the same there on a bunch of them, separated
by only a few days. For example, in system32 I found MCIWAVE.DRV with a
creation date of Aug 10, 2004 and a modified date of Aug 4, 2004 (which,
granted, seems a bit odd).
But I found another file (d3d8.dll) in system32 dated:
Creation date Aug 2004
Modified date April 2008. So, whatever.
J. P. Gilliver (John)
<lo...@sig.bcause.this.is.invalid> writes:
[]
>So to be able to know that date for all files, that's why i said that
>the terminology (and the reality of a property-page) ought to provide
>for two creation-dates to be given for each file; one
>instance-dependent that differs for each particular instance (like you
>see today), and one constant instance-oblivious creation-date for the
>original creation (of the container/content). And no, the latter is not
>the same thing as the modification date.
>
>
date (and another for modified), so saying what it ought to do won't get
you anywhere. Someone at some point decided that the date by default
inserted in that field will be the date on which the file was copied to
or created on that particular machine; sometimes if the file is
installed rather than copied (this can include extracting from a .zip
file - may depend on what you unzip it with), then the date of the copy
that went into the .zip (the .zip format _does_ record that information)
may be used instead.
There are utilities that can tweak the date to anything you like
(including the old Xtree Gold!); some will let you tweak all the dates,
including the modified and accessed ones.
I guess the justification for the default being the date the local copy
was created is that it gives you _some_ hint as to whether what you have
may have been fiddled with if it's newer than the original; however,
since the date field _can_ be modified (and _is_ by default, for most
things that involve _installing_ files, i. e. unzipping or otherwise
extracting them from a downloaded file), this isn't _very_ reliable.
When you just _copy_ a file - *including download* by ftp, http, or most
of the other means (including email attachment) - no date comes with it,
so your system can only give it the current date. (If the creator of the
file itself chose to embed the compilation date, or similar, into the
file itself, that is a different matter, but you'd need the reverse of
whatever s/he used in order to see it - it won't show up in the basic
properties of the file on your system. If what you get is an installer
or .zip file, that _can_ include date information _for the files it
contains_ - not for itself.) If I'm downloading a file from somewhere
that shows its date - ftp sources sometimes do - I tend to use one of
the above utilities to modify the datestamp on my local copy to reflect
that shown, as that at least indicates an earli_er_ date; however, it's
not necessarily the creation date, just the date on which the copy was
placed on the ftp repository. (And even that can I'm sure be tweaked,
though I'd be surprised if that happens much.)
I _think_ the NTFS system may have more "date slots" than the FAT
systems, but I'm not sure about that. But those are still properties of
the system, not the file - so if you fetch (download) a file to such a
system, the date(s) still won't come with it, and it will still have to
use the current date. (I'm not sure about _copying_ NTFS files. But
that's out of scope for this newsgroup.)
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G.5AL-IS-P--Ch++(p)Ar@T0H+Sh0!:`)DNAf
?pu gnickab yb naem uoy tahw siht sI
FromTheRafters
It might help to think of "files" as the labeled shoeboxes you keep
stuff in instead of as the stuff itself. Changing (or relying on) dates
written on the box does not affect the age of the contents. The
filesystem has the marker for writing on the box, but the date
information within (if any) isn't affected by the filesystem.
You might be interested in reading these:
http://www.xxcopy.com/xxcopy15.htm
Gives a sort of history of filesystem stamps as a way of explaining how
the program xxcopy handles them.
http://www.forensickb.com/2009/05/file-system-creation-date-vs-operating.html
Explains how the filesystem is created prior to the OS knowing the
actual time, as a way of warning forensic analysts of a possible logical
pitfall.
Etal
> Etal wrote:
>
>> So to be able to know that date for all files, that's why i
>> said that the terminology (and the reality of a
>> property-page) ought to provide for two creation-dates to be
>> given for each file; one instance-dependent that differs for
>> each particular instance (like you see today), and one
>> constant instance-oblivious creation-date for the original
>> creation (of the container/content). And no, the latter is
>> not the same thing as the modification date.
>>
>>
> Ought to, perhaps; however, the file system only has one slot
> for that date (and another for modified), so saying what it
> ought to do won't get you anywhere.
Huh? what kind of crappy reality is this? I'm gonna go searching
for a better reality.
>
> I guess the justification for the default being the date the
> local copy was created is that it gives you _some_ hint as to
> whether what you have may have been fiddled with if it's newer
> than the original; however, since the date field _can_ be
> modified (and _is_ by default, for most things that involve
> _installing_ files, i. e. unzipping or otherwise extracting
> them from a downloaded file), this isn't _very_ reliable.
>
Yes, for my own comparisons i sometimes make use of the
creation-date that we have and find it useful. For example if i
notice a file i am unsure about ... search my harddisk-volumes
for other files created at that date, sort by time, and one may
discover in what context that file was created.
And yes, i am aware that all timestamps can be manipulated, so
it's something one has to be weary about. I have a utility,
'Properties Plus', installed on one machine here, so can change
any timestamp for my own benefit.
--
"Everybody must get stoned."
Etal
>
> It might help to think of "files" as the labeled shoeboxes you
> keep stuff in instead of as the stuff itself. Changing (or
> relying on) dates written on the box does not affect the age
> of the contents. The filesystem has the marker for writing on
> the box, but the date information within (if any) isn't
> affected by the filesystem.
>
> You might be interested in reading these:
>
> http://www.xxcopy.com/xxcopy15.htm
>
> Gives a sort of history of filesystem stamps as a way of
> explaining how the program xxcopy handles them.
>
> http://www.forensickb.com/2009/05/file-system-creation-date-vs-operating.html
>
>
> Explains how the filesystem is created prior to the OS knowing
> the actual time, as a way of warning forensic analysts of a
> possible logical pitfall.
Ok, i had looked at the references. And yes, living on a rotating
globe adds another dimension to keep in mind.
--
What time is it?
Etal
>> Look at the majority of files in %WinDir%\System\, the ones
>> that have a modification-date of 1998-1999 of the original
>> Win98xE.
>
> Good point - let's go with that...
>
>> The files were obviously created/compiled at that date or
>> earlier, but on your machine they will have the
>> creation-date of what your computers clock were set at when
>> you installed windows.
>
> Huh? I don't think so. I think the date stamp is irrelevant
> of when it was installed on my system. I mean, you just
> made the point - I've got lots of really old files (like DLLs
> and EXEs) that have dates preceding my computer ever being
> here!.
But here i think you are talking about the Mod.-date of the
files. If the creat.-dates are also from before you installed the
OS, the installer that put them there must have overridden
Windows normal way of assigning this timestamp.
>
> For example, a bunch of them are dated 8/4/2004, which has
> nothing to do with when it was installed on my computer. And
> the creation and modification dates are almost the same there
> on a bunch of them, separated by only a few days. For
> example, in system32 I found MCIWAVE.DRV with a creation date
> of Aug 10, 2004 and a modified date of Aug 4, 2004 (which,
> granted, seems a bit odd).
For the 2004-08-04 (mod.-date for most of the WinXP SP2 files)
and creat.-date a few days later ... my guess would be that you
installed SP2 at this date (2004-08-10), shortly after it had
been released.
>
> But I found another file (d3d8.dll) in system32 dated:
> Creation date Aug 2004 Modified date April 2008. So,
> whatever.
>
I think .. (I have it the same on this WinXP machine here) ..
Creat.-date from being installed as part of of WinXP SP2.
Mod.-date from being updated by installing WinXP SP3.
--
Bill in Co
Well, I bought this somewhat customized Dell Inspiron 530 in January 2008,
preloaded with XP SP2, and that's 4 years later than 2004, so I guess that's
not it here.
>>
>> But I found another file (d3d8.dll) in system32 dated:
>> Creation date Aug 2004 Modified date April 2008. So,
>> whatever.
>>
>
> I think .. (I have it the same on this WinXP machine here) ..
> Creat.-date from being installed as part of of WinXP SP2.
> Mod.-date from being updated by installing WinXP SP3.
I installed SP3 last year (2009), so that can't be it for me.
So, I dunno what the story is, but I still suspect it has something to do
with when the file was originally (or finally) compiled and released by MS,
and its being dated with that date stamp.
Etal
The Mod.-date is not related to when the file was installed.
Just like the majority of Mod.-dates for files installed with
WinXP SP3, both our copies of the D3D8.dll file have the
Mod.-date being (2008-04-14) irrespective of when we separately
installed that package. I have a total of 3111 files with that
Mod.-date on this computer and 402 that are dated a day earlier.
> So, I dunno what the story is, but I still suspect it has
> something to do with when the file was originally (or finally)
> compiled and released by MS, and its being dated with that
> date stamp.
>
--
Bill in Co
> Bill in Co wrote:
>
>> Etal wrote:
>>
>>> Bill in Co wrote:
>>>
>
>>>> But I found another file (d3d8.dll) in system32 dated:
>>>> Creation date Aug 2004 Modified date April 2008. So,
>>>> whatever.
>>>>
>>> I think .. (I have it the same on this WinXP machine here) ..
>>> Creat.-date from being installed as part of of WinXP SP2.
>>> Mod.-date from being updated by installing WinXP SP3.
>>
>> I installed SP3 last year (2009), so that can't be it for me.
>>
>
> The Mod.-date is not related to when the file was installed.
> Just like the majority of Mod.-dates for files installed with
> WinXP SP3, both our copies of the D3D8.dll file have the
> Mod.-date being (2008-04-14) irrespective of when we separately
> installed that package. I have a total of 3111 files with that
> Mod.-date on this computer and 402 that are dated a day earlier.
OK, and in retrospect, I think then, overall, the *mod date* is the last
date some certifiable application "touched" (and updated) the file
datestamp. And not all applications change it, but some apparently can and
do (and shouldn't, by the way, at least for some other files I've found on
my system). An example is when some apps open an audio file, and
annoyingly modify its mod date, even if the file has NOT been modified!
This also happens with some IE history urls, too (even if the site has not
been revisited the mod date can get changed just by looking at the history
folder).
I guess one would suspect something like when XP3 was released and issued an
official release date for its files - to be used to identify releases
J. P. Gilliver (John)
>J. P. Gilliver (John) wrote:
>> Ought to, perhaps; however, the file system only has one slot
>> for that date (and another for modified), so saying what it
>> ought to do won't get you anywhere.
>
>Huh? what kind of crappy reality is this? I'm gonna go searching for a
>better reality.
>
modified anyway.
[]
>And yes, i am aware that all timestamps can be manipulated, so it's
>something one has to be weary about. I have a utility, 'Properties
>Plus', installed on one machine here, so can change any timestamp for
>my own benefit.
>
>
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G.5AL-IS-P--Ch++(p)Ar@T0H+Sh0!:`)DNAf
All humanity is divided into three classes: those who are immovable, those who
are movable, and those who move! - Benjamin Franklin
FromTheRafters
That is why I suggested the internal timestamp that *might* be added
when compiled objects are linked. I don't think your utility touches that.
J. P. Gilliver (John)
<err...@nomail.afraid.org> writes:
>Etal wrote:
[]
>> And yes, i am aware that all timestamps can be manipulated, so it's
>> something one has to be weary about. I have a utility, 'Properties
>> Plus', installed on one machine here, so can change any timestamp for my
>> own benefit.
>
>That is why I suggested the internal timestamp that *might* be added
>when compiled objects are linked. I don't think your utility touches
>that.
>
system_ dates; if there's another date actually included somehow in the
bytes of a file, PP won't even know about it.
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G.5AL-IS-P--Ch++(p)Ar@T0H+Sh0!:`)DNAf
Proofread carefully to see if you any words out.
Etal
> Etal wrote:
>
>>> Etal wrote:
>>>
>>>> The terminology used is actually insufficient. It
>>>> doesn't (allow to) differentiate between the
>>>> creation-date of a file and the creation-date of an
>>>> _instance_ of a file.
>>>>
>>>> When it comes to digital files, what is the difference
>>>> between a copy of the original and that of the original
>>>> copy? .. i mean except for the different creation dates
>>>> of the file-instances.
>>>
[snip]
>>>
>> It seems that the people that creates the file-systems,
>> operating-system, copy-routines and file-transfer protocols
>> thinks that the creation-date of a particular instance of a
>> file that is what is important (for the most part).
>>
>> Me, i'd like there to be provisions to see two (different)
>> creation-dates for each file.
>>
>
> It might help to think of "files" as the labeled shoeboxes you
> keep stuff in instead of as the stuff itself. Changing (or
> relying on) dates written on the box does not affect the age
> of the contents. The filesystem has the marker for writing on
> the box, but the date information within (if any) isn't
> affected by the filesystem.
>
> You might be interested in reading these:
>
> http://www.xxcopy.com/xxcopy15.htm
>
> Gives a sort of history of filesystem stamps as a way of
> explaining how the program xxcopy handles them.
>
A page on the official site for XXCopy, a utility where for the
sake of its users, the developers/authors must be concerned with
the way Windows handles the various timestamps.
And they as programmers looking at the definitions in documents
and in the various API's to use and so on, they describe the
situation as more or less FUBARed; i quote:
"It seems that the purpose of three distinct variations in the
file date values were never clearly defined by the designer of
the feature." and "you will find many inconsistent usages in the
File-Create date."
While their conclusion is that "the inconsistencies listed [...]
make the File-Create date unfit for a general-purpose file
selection" .. unless the user has full control and knows what
[s]he is doing.
My conclusion of this situation was/is to point out that "the
terminology used is actually insufficient" and that there should
be two different & clear definitions for the different ways that
that single timestamp is used for under different circumstances.
---------------
Anyways! ... here are two inconsistencies i have noticed
with the behavior of the File-Created date, and anyone still
reading might be interested in performing the experiments on
their own.
[Preparation] it might be easier if you can have two folders from
different volumes open at the same time so instead of the single
folder Windows Explorer by default allow you to have go to
"Folder Options" change to "Browse Folders" -> "Open each folder
in its own window"
[Case01] (Win98 & WinXP)
A) Copy a file from a CD-ROM to a FAT32 volume and you see that
the creation date timestamp of the new copy is set to /CurrentDate/ .
B) This time use Windows Explorers "Move" to /move/ a file from
the CD-ROM to the FAT32 volume. You will get two dialog boxes,
first an "are you sure?", and then an error-dialog[*1] with two
options. however using either option result in a file on the
FAT32. The creation date timestamp of the copy of the file on
FAT32 is this time set to remain as it is/(was) on the file on
the CD-ROM.
While on a certain abstraction-level it makes sense that a
move-command retains the created timestamp of the where it was
moved from, note that in both A) and B) here we end up with two
copies of of the file; the original on the CD-ROM can't be "moved".
[Case02] (WinXP (żWin98?))
(I only have one volume on the Win98 machine next to me so
perhaps someone else can post how it works there if you have
multiple FAT32 volumes. I tested to/from a floppy but that didn't
work.)
Start with one FileA in a FolderA on VolumeA
Start with one FileB in a FolderB on VolumeB
Note the created timestamps on the files.
"Move" FileA to FolderB on VolumeB (note that the created
timestamp has been retained)
Now "Copy" first FileA and then also "Copy" FileB to FolderA on
VolumeA. Now look at the created timestamps on the files in
FolderA and note that while FileB's timestamp has been changed to
/CurrentDate/ like is normal with a copy operation that FileA
surprisingly has retained the Created timestamp from its copy on
another volume.
Now, in this last experiment one use the same copy-command on two
files from and to the same folder, one end up with two copies of
each file, and yet the two copied files end up having different
Created timestamps. This behavior doesn't make any sense to me on
any abstraction-level.
--
Etal
> Etal wrote:
>>
>> And yes, i am aware that all timestamps can be manipulated,
>> so it's something one has to be weary about. I have a
>> utility, 'Properties Plus', installed on one machine here,
>> so can change any timestamp for my own benefit.
>
> That is why I suggested the internal timestamp that *might* be
> added when compiled objects are linked. I don't think your
> utility touches that.
>
(I think you have the same creation-date as the FtR posting in
the (Anti-)Viral groups so i know that you know this and more and
with what seems to be our different views on this i read your
comment as sarcasm.)
Ha-ha. No, no of course i doesn't. This program is of the many
'touch' type-programs and lets you set the extrinsic timestamps
that the filesystem and operating system are concerned with and
what we mostly have been talking about.
The internal timestamps you mention are present in in various
file-formats. It's in some movie file formats, it (can) be in
PDF-format files and in compiled binary files and so on. And each
different format will have it's own definition of how to store,
read and i suppose possibly edit that timestamp. And you may use
special programs different for each one ... Dependency Walker for
one, Acrobat Reader for another and still a different one to view
when a movie-codec was used to encode your WMV-format movie.
Or, of course, sometimes you can find these internal timestamps
by viewing the files with a Plain-Text editor or a Hex-viewer.
--
Etal
> OK, I forgot the "accessed" one. Not all app.s result in that
> being modified anyway.
I think of the "accessed" one as an example of quantum physics.
You can't measure it's value (look at it, study it) without it
changing.
The problem with it is that the GUI-app., Windows Explorer, that
comes with Windows that are meant to access it, by pulling up the
files property-sheet, DO change it.
--
Bill in Co
I tried copying and moving a file between two FAT32 partitions. The result
was:
If copying, the create date on the copied file was set to the time of the
copy, and the modified date stayed the same as on the source file.
If moving (by cut and paste, or by dragging and then selecting the move
option), I got the same results.
But if I copied it directly by selecting it with the mouse and dragging it
(with no prompts - which defaults to copying it), it changed the create date
to the time of the copy.
With directories, I seem to recall this behavior:
If you move (NOT COPY) a subdirectory to another area of the same partition,
it retains the directory datestamp. But if you move OR copy it to another
partition or drive it datestamps it with the time of the move OR copy
operation.
MyNews
The creation-date will be the same
and afterwards unclick Read Only!
and the except for the different creation dates of the file-instances you
will have!
MyNews
Modified: see the creation date
when Copy it see a New creation this is Created when Paste are moved!
But you can in some file not all Right Hand Click go to properties
Chick on the Tab Summary in the Comments put the Date of creation
Then Right chick Folder >View > Details >
Then chick Comment and it line up to Date of creation!
it's work but the only way I know how!
"MyNews" <myn...@comcast.net> wrote in message
news:ieesr1$lor$1...@speranza.aioe.org...
FromTheRafters
> (I only have one volume on the Win98 machine next to me so perhaps
> someone else can post how it works there if you have multiple FAT32
> volumes. I tested to/from a floppy but that didn't work.)
> Start with one FileA in a FolderA on VolumeA
> Start with one FileB in a FolderB on VolumeB
> Note the created timestamps on the files.
> "Move" FileA to FolderB on VolumeB (note that the created timestamp has
> been retained)
> Now "Copy" first FileA and then also "Copy" FileB to FolderA on VolumeA.
> Now look at the created timestamps on the files in FolderA and note that
> while FileB's timestamp has been changed to /CurrentDate/ like is normal
> with a copy operation that FileA surprisingly has retained the Created
> timestamp from its copy on another volume.
>
> Now, in this last experiment one use the same copy-command on two files
> from and to the same folder, one end up with two copies of each file,
> and yet the two copied files end up having different Created timestamps.
> This behavior doesn't make any sense to me on any abstraction-level.
>
>
data for a program or to be consumed by a program. The dates will
pertain to the files, not the contents. So the terminology is sufficient
to what it actually describes.
Within a volume, moving (or copying) a file might not involve any file
manipulation at all (so the stamps are retained) while moving to another
volume does involve file manipulation (creation of the new, and deletion
of the old).
Folders are GUI representations of directories, and moving an icon from
one folder to another looks the same to the user whether or not any file
manipulations took place.
FromTheRafters
>> that single timestamp is used for under different circumstances.
>>
>>
>> ---------------
>>
>> Anyways! ... here are two inconsistencies i have noticed
>> with the behavior of the File-Created date, and anyone still
>> reading might be interested in performing the experiments on
>> their own.
>>
>> [Preparation] it might be easier if you can have two folders from
>> different volumes open at the same time so instead of the single
>> folder Windows Explorer by default allow you to have go to
>> "Folder Options" change to "Browse Folders" -> "Open each folder
>> in its own window"
>>
Are you saying here that it always changed the create date to the time
of the copy? Or did you mean that the last scenario resulted did not?
The above scenarios all look like they should act the same, but I'm
thinking that the drag and drop might be more atomic by bypassing the
transparent 'copy to clipboard'.
> With directories, I seem to recall this behavior:
> If you move (NOT COPY) a subdirectory to another area of the same partition,
> it retains the directory datestamp. But if you move OR copy it to another
> partition or drive it datestamps it with the time of the move OR copy
> operation.
That's how I remember it, and it may be because within a volume, even a
copy may not result in file manipulation, only the "path" to the file on
disk is changed, not the file itself.
It makes sense to not file multiple copiesof the same data on a disk
(redundant data just consumes space) and to just have two paths which
the user "sees" as two icons, one in each "folder". If the user only
modifies "one" of the "copies" then a file manipulation must occur and a
new file creation date (the filesystem is only just now actually
*creating* a file in a directory even though the GUI had already created
an icon in a folder to represent a copy that didn't actually happen as
far as the file/filesystem is concerned.
FromTheRafters
Not sarcasm (but I can see how it could be seen as such), but just
trying to point out that the timestamps you are discussing are all about
tracking file manipulations (even applicable to zero length files). If
you want the newer version of a program (not a file), the filesystem
timestamps are of no real value.
Bill in Co
My bad. (did I really write that? geeesh :-)
Yes, I meant it always changed the create date to the time of the copy.
> The above scenarios all look like they should act the same, but I'm
> thinking that the drag and drop might be more atomic by bypassing the
> transparent 'copy to clipboard'.
>
>> With directories, I seem to recall this behavior:
>> If you move (NOT COPY) a subdirectory to another area of the same
>> partition,
>> it retains the directory datestamp. But if you move OR copy it to
>> another
>> partition or drive, it datestamps it with the time of the move OR copy
>> operation.
>
> That's how I remember it, and it may be because within a volume, even a
> copy may not result in file manipulation, only the "path" to the file on
> disk is changed, not the file itself.
That's what I think too. It's like a pointer. In fact, I'm pretty sure
that if you just "move" the file it doesn't physically move anything on the
disk UNLESS you are moving it to another disk or partition. You're just
changing a pointer to its location.
> It makes sense to not [have] file multiple copies of the same data on a
FromTheRafters
> FromTheRafters wrote:
[...]
>> That's how I remember it, and it may be because within a volume, even a
>> copy may not result in file manipulation, only the "path" to the file on
>> disk is changed, not the file itself.
>
> That's what I think too. It's like a pointer. In fact, I'm pretty sure
> that if you just "move" the file it doesn't physically move anything on the
> disk UNLESS you are moving it to another disk or partition. You're just
> changing a pointer to its location.
Funny you should say that, because 'just a move' actually involves a
copy followed by a delete (so a 'move' is actually more than 'just a
copy') :o)
Your point is correct though I think, since both copy and delete are
done external to the file. The copy makes two paths point to the same
data, and the delete removes the old path. Do it across volumes and you
must read the file's content and write it to a new location into a newly
created file and then delete the old reference path (which allows the
clusters it formerly pointed to to be reused).
[...]
Bill in Co
> Bill in Co wrote:
>> FromTheRafters wrote:
> [...]
>
>>> That's how I remember it, and it may be because within a volume, even a
>>> copy may not result in file manipulation, only the "path" to the file on
>>> disk is changed, not the file itself.
>>
>> That's what I think too. It's like a pointer. In fact, I'm pretty
>> sure
>> that if you just "move" the file it doesn't physically move anything on
>> the
>> disk UNLESS you are moving it to another disk or partition. You're just
>> changing a pointer to its location.
>
> Funny you should say that, because 'just a move' actually involves a
> copy followed by a delete (so a 'move' is actually more than 'just a
> copy') :o)
>
> Your point is correct though I think, since both copy and delete are
> done external to the file. The copy makes two paths point to the same
> data, and the delete removes the old path.
No, a file "copy" operation actually makes another file copy (not talking
about just copying "shortcuts" here). A "move" operation (within the same
disk partition) does not. That's a huge difference.
MyNews
news:iefua0$396$1...@news.eternal-september.org...
You 100% right on that info FromTheRafters!
J. P. Gilliver (John)
<err...@nomail.afraid.org> writes:
[]
>That's how I remember it, and it may be because within a volume, even a
>copy may not result in file manipulation, only the "path" to the file
>on disk is changed, not the file itself.
>
>It makes sense to not file multiple copiesof the same data on a disk
>(redundant data just consumes space) and to just have two paths which
>the user "sees" as two icons, one in each "folder". If the user only
>modifies "one" of the "copies" then a file manipulation must occur and
>a new file creation date (the filesystem is only just now actually
>*creating* a file in a directory even though the GUI had already
>created an icon in a folder to represent a copy that didn't actually
>happen as far as the file/filesystem is concerned.
>
modifying a pointer, but I'm pretty sure a copy will result in a second
set of bytes actually being created. Otherwise, the OS would have to
remember - maybe for years later - all the "pairs". (_Could_ be done by
having a marker as part of the directory entry - would have to be by
_both_ directory entries, as the OS doesn't know which one the user
might subsequently try to edit - but I'm not aware of any such
provision.)
Easy to establish, though: note the "free space" on a partition, copy a
(reasonably big) file, and see if the free space has dropped by the size
of the file, or just by the size of some pointer/flag/whatever.
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G.5AL-IS-P--Ch++(p)Ar@T0H+Sh0!:`)DNAf
A language is a dialect that has an army and a navy. -Max Weinreich, linguist
and author (1894-1969)
Bill Blanton
Actually though in a move, (in the same volume) there are two data
clusters written to. A directory is a file itself that keeps the file
start cluster chain pointer and "attributes" in its data clusters. If
you move a file or a subdir from one dir to another, both the old and
new dir's data clusters are modified.
On timestamps. This is from MS's FAT spec describing the fields relating
to date and time in the directory entry structures.
DIR_CrtTime Time file was created.
DIR_CrtDate Date file was created.
DIR_LstAccDate Last access date. Note that there is no last access
time, only a date. This is the date of last read or write. In the case of a
write, this should be set to the same date as DIR_WrtDate.
DIR_WrtTime Time of last write. Note that file creation is considered a
write.
DIR_WrtDate Date of last write. Note that file creation is considered a
write.
Bill Blanton
I think Rafters is saying that in order to do a move, you'd need to copy
the file entry to the new dir then delete the original. OTOH, it could
be a copy to memory, then delete, then write to the new. In case of a
mishap, the first could cause crosslinked files, the latter orphaned
clusters.
I would think the copy then del method would be safer in a data recovery
context.
FromTheRafters
Good point, a directory is just a file getting treated differently by
the system. So, operations affecting outside the file in question
actually does affect another file. However, there is no requirement for
the subject file's data to be read from and written to anywhere within a
volume when affecting the directory (file) accomplishes the same thing
as far as the user is concerned.
Rather than spend computing time in transferring a large files data to
another location on the volume when doing a copy (resulting in redundant
data) the subsystem merely creates another directory data entry to point
to the already existing data. Only when the file's data is changed in
one 'path' but not the other, does there need to be actual data read and
write upon saving the changes.
> On timestamps. This is from MS's FAT spec describing the fields relating
> to date and time in the directory entry structures.
>
> DIR_CrtTime Time file was created.
> DIR_CrtDate Date file was created.
>
> DIR_LstAccDate Last access date. Note that there is no last access
> time, only a date. This is the date of last read or write. In the case of a
> write, this should be set to the same date as DIR_WrtDate.
>
> DIR_WrtTime Time of last write. Note that file creation is considered a
> write.
> DIR_WrtDate Date of last write. Note that file creation is considered a
> write.
Very similar to regular file stamps, eh?
FromTheRafters
> <err...@nomail.afraid.org> writes:
> []
>> That's how I remember it, and it may be because within a volume, even
>> a copy may not result in file manipulation, only the "path" to the
>> file on disk is changed, not the file itself.
>>
>> It makes sense to not file multiple copiesof the same data on a disk
>> (redundant data just consumes space) and to just have two paths which
>> the user "sees" as two icons, one in each "folder". If the user only
>> modifies "one" of the "copies" then a file manipulation must occur and
>> a new file creation date (the filesystem is only just now actually
>> *creating* a file in a directory even though the GUI had already
>> created an icon in a folder to represent a copy that didn't actually
>> happen as far as the file/filesystem is concerned.
>>
> Hmm. A move (within the same partition) could indeed just involve
> modifying a pointer, but I'm pretty sure a copy will result in a second
> set of bytes actually being created. Otherwise, the OS would have to
> remember - maybe for years later - all the "pairs". (_Could_ be done by
> having a marker as part of the directory entry - would have to be by
> _both_ directory entries, as the OS doesn't know which one the user
> might subsequently try to edit - but I'm not aware of any such provision.)
>
> Easy to establish, though: note the "free space" on a partition, copy a
> (reasonably big) file, and see if the free space has dropped by the size
> of the file, or just by the size of some pointer/flag/whatever.
As I remember it, you could see how long it takes to accomplish copying
a very large file as opposed to just creating a symbolic link or
whatever they call it. Time to copy large file within volume, as opposed
to time to copy large file to another volume on the same disk.
Your way is probably more trustworthy.
FromTheRafters
> FromTheRafters wrote:
>> Bill in Co wrote:
>>> FromTheRafters wrote:
>> [...]
>>
>>>> That's how I remember it, and it may be because within a volume, even a
>>>> copy may not result in file manipulation, only the "path" to the file on
>>>> disk is changed, not the file itself.
>>>
>>> That's what I think too. It's like a pointer. In fact, I'm pretty
>>> sure
>>> that if you just "move" the file it doesn't physically move anything on
>>> the
>>> disk UNLESS you are moving it to another disk or partition. You're just
>>> changing a pointer to its location.
>>
>> Funny you should say that, because 'just a move' actually involves a
>> copy followed by a delete (so a 'move' is actually more than 'just a
>> copy') :o)
>>
>> Your point is correct though I think, since both copy and delete are
>> done external to the file. The copy makes two paths point to the same
>> data, and the delete removes the old path.
>
> No, a file "copy" operation actually makes another file copy (not talking
> about just copying "shortcuts" here).
I'm not as sure about that as you are. It certainly appears to the user
that an actual copy operation is being done (read from one place and
write to another), I was just mentioning that an actual move is the same
thing *plus* a following delete operation (read, write, delete reference
to file in old location).
The perhaps more 'smoke and mirrors' *file copy* operation might not be
so straightforward.
You may be right about the rest (FAT), I don't know, but it seems silly
to copy all that redundant data to so many new clusters when a new
directory entry can be so easily created to point to the same cluster
and give the user the same effect.
[...]
J. P. Gilliver (John)
<err...@nomail.afraid.org> writes:
[]
>Rather than spend computing time in transferring a large files data to
>another location on the volume when doing a copy (resulting in
>redundant data) the subsystem merely creates another directory data
>entry to point to the already existing data. Only when the file's data
>is changed in one 'path' but not the other, does there need to be
>actual data read and write upon saving the changes.
So how does the system remember that all these pairs of "files" exist -
maybe years later, and maybe the actual disc has been moved to another
computer?
In other words, when I edit (or delete) a file, how does the system
"know" that it's one of two "files" that point to the same actual data
on the disc, as opposed to it being a unique single file I'm
editing/deleting?
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G.5AL-IS-P--Ch++(p)Ar@T0H+Sh0!:`)DNAf
Veni Vidi Visa [I came, I saw, I did a little shopping] - Mik from S+AS Limited
(m...@saslimited.demon.co.uk), 1998
FromTheRafters
> <err...@nomail.afraid.org> writes:
> []
>> Rather than spend computing time in transferring a large files data to
>> another location on the volume when doing a copy (resulting in
>> redundant data) the subsystem merely creates another directory data
>> entry to point to the already existing data. Only when the file's data
>> is changed in one 'path' but not the other, does there need to be
>> actual data read and write upon saving the changes.
> []
> So how does the system remember that all these pairs of "files" exist -
> maybe years later, and maybe the actual disc has been moved to another
> computer?
I don't know, and as I said I don't know if FAT does this or even NTFS.
It would neatly explain why file timestamps behave the way they do when
copying across volumes as opposed to within a volume.
Bill in Co
Smoke and mirrors?
> You may be right about the rest (FAT), I don't know, but it seems silly
> to copy all that redundant data to so many new clusters when a new
> directory entry can be so easily created to point to the same cluster
> and give the user the same effect.
> [...]
I don't see how that would work, since I think you want two *independent*
file copies on the disk, so that either file can be modified without
affecting the other.
The only way to do that I believe is to store two separate (but initially
identical) files on the disk (I'm not talking about the directory entries
here; I'm talking about the actual files themselves)
FromTheRafters
The idea would be to create that independent file when you have made a
change to the data via a certain path. At that point a new file would be
created, then, *that* directory entry would point to the *new* starting
cluster (and the others would still point to the original starting cluster).
I don't yet see why the system would have to track all of the "pairs" as
John suggests - unless it wants to synchronize the files. The user
wouldn't need to know that distinct paths sometimes led to the same
cluster chain.
> The only way to do that I believe is to store two separate (but initially
> identical) files on the disk (I'm not talking about the directory entries
> here; I'm talking about the actual files themselves)
I'm just suggesting that they need not be separate clusters until they
are "different" data, and this would explain the seeming timestamp
anomalies noted when copying across a partition boundary or not.
I can see no other reason for the anomalies than the possibility that
sometimes a "file copy" doesn't actually touch the file it is copying
nor actually *create* a new file (with new new clusters) on the
filesystem until the data being stored in the clusters are different.
If my premise is wrong (which is not out of the realm of possibilities),
then we're still at a loss to explain the noted behavior.
J. P. Gilliver (John)
<err...@nomail.afraid.org> writes:
>Bill in Co wrote:
[]
>> I don't see how that would work, since I think you want two *independent*
>> file copies on the disk, so that either file can be modified without
>> affecting the other.
>
>The idea would be to create that independent file when you have made a
>change to the data via a certain path. At that point a new file would
>be created, then, *that* directory entry would point to the *new*
>starting cluster (and the others would still point to the original
>starting cluster).
How would the OS "know" that the original set of clusters have to be
retained and aren't now free space?
>
>I don't yet see why the system would have to track all of the "pairs"
>as John suggests - unless it wants to synchronize the files. The user
>wouldn't need to know that distinct paths sometimes led to the same
>cluster chain.
The user certainly wouldn't, but the OS or file system would.
>
>> The only way to do that I believe is to store two separate (but initially
>> identical) files on the disk (I'm not talking about the directory entries
>> here; I'm talking about the actual files themselves)
>
>I'm just suggesting that they need not be separate clusters until they
>are "different" data, and this would explain the seeming timestamp
>anomalies noted when copying across a partition boundary or not.
>
>I can see no other reason for the anomalies than the possibility that
>sometimes a "file copy" doesn't actually touch the file it is copying
>nor actually *create* a new file (with new new clusters) on the
>filesystem until the data being stored in the clusters are different.
I can see where you're coming from, I just don't think that's what
actually happens. As I said in an earlier post, it can easily be
established one way on another by noting the alleged free space on a
volume, then copying a (largish) file (that already exists on the
volume) so that two copies of it now exist on the one volume, then
checking the free space again, and seeing if it has gone down by
approximately the size of the file, or not.
>
>If my premise is wrong (which is not out of the realm of
>possibilities), then we're still at a loss to explain the noted
>behavior.
>
>
>
Bill in Co
I'm pretty sure it does. :-)
That is, every time you copy a file, it decreases the available free disk
space by the amount needed, and that's based on the number of clusters it
needs, which in turn is a function of the file's filesize and the number of
bytes allocated per cluster. (I think it's 4096 bytes per cluster using
the default NTFS parameters). But as you said, it's easy to check out.
Etal
> J. P. Gilliver (John) wrote:
>
>> FromTheRafters writes:
>>
>>> Rather than spend computing time in transferring a large
>>> files data to another location on the volume when doing a
>>> copy (resulting in redundant data) the subsystem merely
>>> creates another directory data entry to point to the
>>> already existing data. Only when the file's data is
>>> changed in one 'path' but not the other, does there need
>>> to be actual data read and write upon saving the changes.
>>
>> []
>> So how does the system remember that all these pairs of
>> "files" exist - maybe years later, and maybe the actual disc
>> has been moved to another computer?
>
> I don't know, and as I said I don't know if FAT does this or
> even NTFS. It would neatly explain why file timestamps behave
> the way they do when copying across volumes as opposed to
> within a volume.
>
I think you are trying to invent HardLinks. Something already
implemented for WinNT under NTFS (since Win2k0). But if using
Windows (Win98xE), or FAT under any OS, a copy command needs to
make another actual copy of the file even on the same volume.
<http://en.wikipedia.org/wiki/Hard_link>
--
When my link-counter reaches zero, i cease to exist
Lee
snip
> 6.00.8397.0 (Came with Win98 & both IE5.5 & IE6)
> 6.00.8797.0 (My current version - but where did I get it?)
snip
>
> --
> Thanks or Good Luck,
> There may be humor in this post, and,
> Naturally, you will not sue,
> Should things get worse after this,
> PCR
> pcr...@netzero.net
Visual C++ 6.0 Runtime
http://support.microsoft.com/?kbid=259403
FromTheRafters
made the timestamps work the way that they do so as to be consistent
with filesystems that do indeed do as I suggested.
Anyway, it seems we've beaten this to death.
MyNews
For good Info FromTheRafters
PCR
OK. I see it came from that update, as I did begin to dimly recall on my
own. But thanks, Lee, & glad to see you still are around.
Etal
> That could very well be. It could also be that Microsoft
> purposefully made the timestamps work the way that they do so
> as to be consistent with filesystems that do indeed do as I
> suggested.
>
> Anyway, it seems we've beaten this to death.
>
And what did it all have to do with any version of msvcrt.dll anyhow.
--
Bill in Co
Probably the version, which is correlated to the dll file's datestamp.
IOW, by looking at the datestamp of system DLL files, one can determine
which version or update of windows it was installed with.
FromTheRafters
The uselessness of using file create dates to determine how recent your
version is was being explored. File create dates have little to do with
the age of the file's content.