Microsoft's perennial incompetence...

[Paul]

Another idiotic answer...

Hmmm.

Now this looks interesting. "Copy" versus "Move". Different semantics.

http://support.microsoft.com/kb/299648

Paul

 

[Ed Propes]

I'm not sure it is a clock problem but maybe a date format
problem. The date could be 2013 Nov 23rd. It is strange either
way.

Ed P

Paul laid this down on his screen :

 

[John Doe]

Hmmm.

Now this looks interesting. "Copy" versus "Move". Different
semantics.

http://support.microsoft.com/kb/299648

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.

 

[Gene E. Bloch]

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]

The file was *created on the new computer* when it was copied to
the new computer.

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.

It's not rocket science...

Apparently it is, to some...

--

 

[DevilsPGD]

Microsoft-speak aside, the file creation date should be the date I
create the file, not the date the file is copied.

It isn't. It's the date the file was created in the file system, nothing
more, nothing less.

 

[John Doe]

Bullshit troll...

--

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.

 

[Ken Springer]

Hmmm.

Now this looks interesting. "Copy" versus "Move". Different semantics.

http://support.microsoft.com/kb/299648

Paul

Thanks for this link, Paul.


--
Ken

Mac OS X 10.8.5
Firefox 24.0
Thunderbird 17.0.8

 

[Ken Springer]

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.

I don't think the average computer user even has a clue. :-( Too many
basics of computers are not part of their knowledge base, and they don't
care to learn for various reasons, until disaster strikes. "Blob of
files on their hard drive", if they even know what a hard drive is, I
think pretty much sums it up.


--
Ken

Mac OS X 10.8.5
Firefox 24.0
Thunderbird 17.0.8

 

[Loren Pechtel]

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.

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

 

[DevilsPGD]

In the last episode of <[email protected]>,

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

You also need to allow for time rounding, since FAT only uses 2 second
increments while NTFS allows for far greater accuracy.

 

[John Doe]

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 think we found the culprit...

--

 

[Gene E. Bloch]

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.

Rather egregious non-sequitur...

Apparently it is, to some...

Evidently...

 

[John Doe]

Pure bullshit...

--

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

 

[John Doe]

A troll acting like it has no idea what "create" means...

--

 

[Ken Springer]

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.

Agreed, although maybe not necessarily a programmer, just recording the
actual timestamp. I'm thinking camera images, here.

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?

I think this is John's point, and mine, there should be two types of
creation dates. Maybe more, depending on the need for multiple timestamps.

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.

IMO, the date of the archive file itself should be the date the archive
file was created, but the timestamps of the data in the archive should
remain unchanged.

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?

Since the contents of any file is the truly important part, if the
contents are not changed, timestamps are should not be changed. Since
you can't easily, at least for most users, work on a file in any
archive, I wouldn't place as much importance on the timestamp for an
archive file.

But, at some point, regardless of what timestamps do, users need to know
what's going on without confusion. IMO, Windows fails in this regard.

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?

That original creation date is, I think, the subject. And, since
there's more than one point of "which creation date are we talking
about", there needs to be more than one, and differing names to let the
user know which one we're talking about.


--
Ken

Mac OS X 10.8.5
Firefox 24.0
Thunderbird 17.0.8

 

[John Doe]

It isn't. It's the date the file was created in the file system,
nothing more, nothing less.

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.

 

[dadiOH]

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

No, it's not. So why are you having so much trouble understanding that the
creation date of a file copy is the date you copied it?

--

dadiOH
____________________________

Winters getting colder? Tired of the rat race?
Taxes out of hand? Maybe just ready for a change?
Check it out... http://www.floridaloghouse.net

 

[dadiOH]

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.

1. Move file = one file

2. Copy file = two files...the original and the new one that was just
CREATED

I bet you have difficulty with life in general, don't you.

--

dadiOH
____________________________

Winters getting colder? Tired of the rat race?
Taxes out of hand? Maybe just ready for a change?
Check it out... http://www.floridaloghouse.net

 

[dadiOH]

Another idiotic answer...

I'm sorry it is too complex for whatever passes for your brain.

--

dadiOH
____________________________

Winters getting colder? Tired of the rat race?
Taxes out of hand? Maybe just ready for a change?
Check it out... http://www.floridaloghouse.net