P
Paul
John said:Another idiotic answer...
Hmmm.
Now this looks interesting. "Copy" versus "Move". Different semantics.
http://support.microsoft.com/kb/299648
Paul
John said:Another idiotic answer...
Paul said:Hmmm.
Now this looks interesting. "Copy" versus "Move". Different
semantics.
http://support.microsoft.com/kb/299648
dadiOH said:When you copy a file, the "creation date"
To an English speaker, the term "creation date" is very easily
understood to be the date that the file was created by the user.
It has an ordinary English meaning. And then there's the fact that
knowing when I created the file can be very useful. Like when I
started keeping track of something. It's not rocket science...
[the creation date] of the original file becomes the "modified
date" of the copy.
The modified date is not the creation date.
Microsoft's aim is to please the masses. Ignorance is bliss.
The file was *created on the new computer* when it was copied to
the new computer.
It's not rocket science...
John Doe said:Microsoft-speak aside, the file creation date should be the date I
create the file, not the date the file is copied.
DevilsPGD said:Path: eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!news.albasani.net!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: DevilsPGD <boogabooga crazyhat.net>
Newsgroups: alt.comp.hardware.pc-homebuilt,alt.comp.os.windows-8
Subject: Re: Microsoft's perennial incompetence...
Date: Mon, 25 Nov 2013 14:04:59 -0800
Organization: Disorganized
Lines: 11
Message-ID: <mai799t3b0tqep5olnhcb8i4cgin6qr8v3 4ax.com>
References: <l6sjct$nro$2 dont-email.me> <l6tbqd$tqe$1 dont-email.me> <l6tm7a$3h7$1 dont-email.me> <l6vg09$p4b$1 dont-email.me> <l6vvkr$q8d$1 dont-email.me> <1iso4h7k45wuy$.dlg stumbler1907.invalid> <l70h0p$fc3$1 dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Trace: individual.net EwORMniyR4tG92T5ivT6+gxMLkxIeQdAkBcfj/zGwJWZIH4IeM
Cancel-Lock: sha1:2gfenAd8em0Wh/TgDj0qYUDo82A=
User-Agent: ForteAgent/7.10.32.1214
Xref: news.eternal-september.org alt.comp.hardware.pc-homebuilt:28837 alt.comp.os.windows-8:8248
It isn't. It's the date the file was created in the file system, nothing
more, nothing less.
Hmmm.
Now this looks interesting. "Copy" versus "Move". Different semantics.
http://support.microsoft.com/kb/299648
Paul
I think it's as Grinder said, Microsoft is concerned about the
container date, not the date that the user created the file. In
which case, Microsoft should properly name it "date copied" or
whatever. If I were into conspiracy theories, I would think
Microsoft has something against users copying files. This useless
file attribute garbage has been around forever.
I am impressed by how many users can get along without knowing or
caring when they create files. Or maybe they don't know how to
copy files. That does apply to a large number of users. Most users
just look at it as a blob of files on their hard drive that are
stuck there perhaps like clutter on the floor of their room.
If a system clock is wrong on a system, the creation date
could be wrong later.
You're assuming, for some reason, they would correct any
out of range dates. But that would be a mistake, as the date,
even if tragically wrong, should be preserved for later analysis
and correction (as needed).
On the file systems, NTFS uses UTC. FAT32 uses DST, and it's
more possible to see peculiar situations on FAT32, than on
NTFS. (Like, copy files between NTFS and FAT32, and the
translation between UTC and DST etc. Lots of permutations
and combinations there are possible. And a headache for
the people designing backup software.)
And changing the FAT32 spec now, is not an option.
It has to be left broken, for compatibility with all
those hardware boxes also implementing FAT32 that way.
Loren Pechtel said:Yeah, I've had all sorts of problems with daylight savings and NTFS
<-> FAT32-emulating file systems. My backup program even specifically
considers files that differ by exactly an hour to have the same
timestamp. (And I've managed to fool even that--by the right sequence
of operations over time I've gotten a timestamp two hours off.)
generic said:The "actual"/real creation date of a file(s) is the date that it was
compiled & linked to be an executable by the original programmer.
It is "not" the date on that appears in the OS; semantics? yes.
I see... Software pirates aren't *copying*, they're *creating*!
"I didn't steal it, judge, I created the file right there on my
own computer!"
Microsoft-speak aside, the file creation date should be the date I
create the file, not the date the file is copied.
Apparently it is, to some...
Gene E. Bloch said:Path: eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!news.albasani.net!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: "Gene E. Bloch" <not-me other.invalid>
Newsgroups: alt.comp.hardware.pc-homebuilt,alt.comp.os.windows-8
Subject: Re: Microsoft's perennial incompetence...
Date: Mon, 25 Nov 2013 20:08:27 -0800
Organization: Astrolabe
Lines: 43
Message-ID: <jxopiefis8vm.dlg stumbler1907.invalid>
References: <l6sjct$nro$2 dont-email.me> <l6tbqd$tqe$1 dont-email.me> <l6tm7a$3h7$1 dont-email.me> <l6vg09$p4b$1 dont-email.me> <l6vvkr$q8d$1 dont-email.me> <1iso4h7k45wuy$.dlg stumbler1907.invalid> <l70h0p$fc3$1 dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Trace: individual.net JME1S45mhfeIPthEp13+MA427z9K1r/kxG32k98FPKrX8AXUa9
Cancel-Lock: sha1:f+zCl01BGRVch98UldbyOSqnD0A=
User-Agent: 40tude_Dialog/2.0.15.84
Xref: news.eternal-september.org alt.comp.hardware.pc-homebuilt:28847 alt.comp.os.windows-8:8264
Rather egregious non-sequitur...
Evidently...
The "actual"/real creation date of a file(s) is the date that it was
compiled & linked to be an executable by the original programmer.
It is "not" the date on that appears in the OS; semantics? yes.
As such, the date need to reflect how the OS sees the presence
of a file. Then when arguing about creation dates, what is the
criteria for the "creation" dates of files residing in a zip/tar file?
And should the "creation" dates of the zip/tar files reflect the date
of its presence after they are unzipped/untar? Or the dates that are
in the zip/tar file which most likely be later than the dates of the
files themselves.
If one changes the attribute of a file, is it really the same file if
the attributes are different? Or having zip/tar files that are
"created" at different timeframes, are the individual files in the
zip/tar files the same file & should have a different "creation" date?
And so on. What is one's definition of the "creation date" considering
the different scenarios? Can the creation date be consistent? & how
does one know the original creation date by the programmer?
DevilsPGD said:It isn't. It's the date the file was created in the file system,
nothing more, nothing less.
John Doe said:To an English speaker, the term "creation date" is very
easily understood to be the date that the file was
created by the user. It has an ordinary English meaning.
And then there's the fact that knowing when I created the
file can be very useful. Like when I started keeping
track of something. It's not rocket science...
John Doe said:To point out how that is so obviously wrong... If that
were true, the "date created" attribute would change when
the file is moved to another hard drive. But it isn't.
The "date created" attribute in fact morphs into the
"date copied" attribute after the actual date created
data is destroyed by Windows Explorer.
John Doe said:Another idiotic answer...