Microsoft's perennial incompetence...

DevilsPGD boogabooga crazyhat.net wrote:

John Doe jdoe usenetlove.invalid wrote:
"Gene E. Bloch" not-me other.invalid wrote:
"John Doe" jdoe usenetlove.invalid wrote

The creation date is obviously the oldest date associated
with the file. Why can't they maintain the oldest date as the
creation date? It's obviously a major blunder that keeps
going and going...

I'm surprised this isn't well-known. All you have to do to
prove it is copy a file from one folder to another. The
creation date changes to the copy date. You might consider
the copy date to be the creation date but I certainly don't,
and it destroys the real creation date of the copied file.
That totally messes up backups if you ever need to use them,
since they are copies.

Or maybe the real creation date is maintained as one of the
other 15 or so different date properties? Please advise.

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

--








--
A fool and his money are soon popular.

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

"John Doe" wrote in message

"dadiOH" dadiOH invalid.com wrote:

"John Doe" jdoe usenetlove.invalid wrote
Paul nospam needed.com wrote:
John Doe wrote:

File attributes: Date Last Saved 13/11/23 Date
Created 13/11/24 That's one thing Windows has
always done wrong and always will.

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

The creation date is obviously the oldest date
associated with the file. Why can't they maintain the
oldest date as the creation date? It's obviously a
major blunder that keeps going and going...

I'm surprised this isn't well-known. All you have to
do to prove it is copy a file from one folder to
another. The creation date changes to the copy date.
You might consider the copy date to be the creation
date but I certainly don't, and it destroys the real
creation date of the copied file. That totally messes
up backups if you ever need to use them, since they
are copies.

Or maybe the real creation date is maintained as one
of the other 15 or so different date properties?
Please advise.

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

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

"John Doe" wrote in message

DevilsPGD boogabooga crazyhat.net wrote:

John Doe jdoe usenetlove.invalid wrote:
"Gene E. Bloch" not-me other.invalid wrote:
"John Doe" jdoe usenetlove.invalid wrote

The creation date is obviously the oldest date
associated with the file. Why can't they maintain
the oldest date as the creation date? It's
obviously a major blunder that keeps going and
going...

I'm surprised this isn't well-known. All you have
to do to prove it is copy a file from one folder
to another. The creation date changes to the copy
date. You might consider the copy date to be the
creation date but I certainly don't, and it
destroys the real creation date of the copied
file. That totally messes up backups if you ever
need to use them, since they are copies.

Or maybe the real creation date is maintained as
one of the other 15 or so different date
properties? Please advise.

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

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

"John Doe" wrote in message

"dadiOH" dadiOH invalid.com wrote:

"John Doe" jdoe usenetlove.invalid wrote
Grinder grinder no.spam.maam.com wrote:
John Doe wrote:

File attributes: Date Last Saved 13/11/23 Date
Created 13/11/24 That's one thing Windows has
always done wrong and always will.

My apologies if this has already been noted
elsewhere, but there is good reason for
CreationDate ModifyDate.

When a file is copied, the copy gets the current
date as a creation date, but the modification date
is copied from the original file.

Yeah, but what happened to the creation date? I guess
that programmers think computers are more important
than people. When
the file is copied, somehow the computer is
"creating" a file. And who cares when the human being
originally created the file...

There are so many file date attributes, you would
think that Microsoft could use one of them for
maintaining when the file was created. And it would
probably be called "date created". If you
want to have a "date copied", fine, but that's a
different attribute.

You have to wonder what they're thinking up there in
Redmond.

They're thinking that when you copy a file the date it
was copied is the
date it was created. They are right. A copied file is
a different entity
than the one from which it was copied.

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

"Ken Springer" wrote in message

On 11/25/13 2:48 PM, Zaphod Beeblebrox wrote:
On Mon, 25 Nov 2013 16:52:40 +0000, "mechanic"
wrote in article
...

On Mon, 25 Nov 2013 07:37:19 -0500, dadiOH wrote:

They're thinking that when you copy a file the date
it was copied is the date it was created. They are
right. A copied file is a different entity than
the one from which it was copied.

So teh copied file will have a different creation
date to that of the original, although the contents
will be the same. Don't rely on OS file meta-data for
user configuration management. f/u set

Exactly, the OS is looking at it from a *gasp* OS
perspective!

And herein lies the problem, methinks. Semantics,
basically.
It seems as if the programmers forgot to take into
consideration it would be people who would reading that information, and
interpret it according to the English language they were
taught, *not* OS perspectives.
Perhaps programmers should be required to have a minor in
English, but unfortunately there's no way to teach them
how to think like a noncomputer person.

I suspect thet even the most extreme "noncomputer" person would agree that
the creation date of something is when it first came into being; ergo, the
creation date of a copy is the date it was copied.

Suppose I have a nice, authentic Louis IV chair and I want another. I hire
someone to make it. He does an excellent job, the new chair is an exact
copy - in the most minute detail - of the original. Despite being an exact
copy, it is NOT a Louis IV chair, it is a copy and its creation date is when
it was made.
___________________

John Doe is correct, there should be a way to tell, by
the date, which file is the actual, true original by
timestamp, and it should not be changed by the system.

There is. It is the "modified" date.

If that is too difficult for our penantic Mr. Doe to use, he could prefix
the copied file with "Copy of file name". If that is too much trouble he
could copy the file into the same folder and MS will insert the prefix
itself.

--

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

On Mon, 25 Nov 2013 20:07:00 -0800, "Gene E. Bloch" not-
lid wrote in article da5fyvg6mt8t
...

On Mon, 25 Nov 2013 23:34:22 +0000, mechanic wrote:

On Mon, 25 Nov 2013 21:55:37 +0000 (UTC), John Doe wrote:

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

It *is* the date the file is created, when you copy a file you
create a file that's a duplicate of the original. What's so hard to
understand?

f/u set

For John Doe, the whole idea...

I think it is more thought in general that challenges it.

--
Zaphod

If I had two heads like you, Zaphod,
I could have hours of fun banging them against a wall.
-Ford Prefect

On 11/26/13 7:11 AM, dadiOH wrote:
"John Doe" wrote in message

"dadiOH" dadiOH invalid.com wrote:

"John Doe" jdoe usenetlove.invalid wrote
Grinder grinder no.spam.maam.com wrote:
John Doe wrote:

File attributes: Date Last Saved 13/11/23 Date
Created 13/11/24 That's one thing Windows has
always done wrong and always will.

My apologies if this has already been noted
elsewhere, but there is good reason for
CreationDate ModifyDate.

When a file is copied, the copy gets the current
date as a creation date, but the modification date
is copied from the original file.

Yeah, but what happened to the creation date? I guess
that programmers think computers are more important
than people. When
the file is copied, somehow the computer is
"creating" a file. And who cares when the human being
originally created the file...

There are so many file date attributes, you would
think that Microsoft could use one of them for
maintaining when the file was created. And it would
probably be called "date created". If you
want to have a "date copied", fine, but that's a
different attribute.

You have to wonder what they're thinking up there in
Redmond.

They're thinking that when you copy a file the date it
was copied is the
date it was created. They are right. A copied file is
a different entity
than the one from which it was copied.

Another idiotic answer...

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

A bit beneath you, dadiOH.


--
Ken

Mac OS X 10.8.5
Firefox 24.0
Thunderbird 17.0.8

On 11/26/13 7:08 AM, dadiOH wrote:
"John Doe" wrote in message

DevilsPGD boogabooga crazyhat.net wrote:

John Doe jdoe usenetlove.invalid wrote:
"Gene E. Bloch" not-me other.invalid wrote:
"John Doe" jdoe usenetlove.invalid wrote

The creation date is obviously the oldest date
associated with the file. Why can't they maintain
the oldest date as the creation date? It's
obviously a major blunder that keeps going and
going...

I'm surprised this isn't well-known. All you have
to do to prove it is copy a file from one folder
to another. The creation date changes to the copy
date. You might consider the copy date to be the
creation date but I certainly don't, and it
destroys the real creation date of the copied
file. That totally messes up backups if you ever
need to use them, since they are copies.

Or maybe the real creation date is maintained as
one of the other 15 or so different date
properties? Please advise.

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

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.

The problem with it working the way #2 operates is it makes the dates
absolutely useless for any kind of sequential data tracking using
timestamps. I think being able to do that is more useful to the user,
and what most users would expect.


--
Ken

Mac OS X 10.8.5
Firefox 24.0
Thunderbird 17.0.8

On 11/26/13 7:30 AM, dadiOH wrote:
"Ken Springer" wrote in message

On 11/25/13 2:48 PM, Zaphod Beeblebrox wrote:
On Mon, 25 Nov 2013 16:52:40 +0000, "mechanic"
wrote in article
...

On Mon, 25 Nov 2013 07:37:19 -0500, dadiOH wrote:

They're thinking that when you copy a file the date
it was copied is the date it was created. They are
right. A copied file is a different entity than
the one from which it was copied.

So teh copied file will have a different creation
date to that of the original, although the contents
will be the same. Don't rely on OS file meta-data for
user configuration management. f/u set

Exactly, the OS is looking at it from a *gasp* OS
perspective!

And herein lies the problem, methinks. Semantics,
basically.
It seems as if the programmers forgot to take into
consideration it would be people who would reading that information, and
interpret it according to the English language they were
taught, *not* OS perspectives.
Perhaps programmers should be required to have a minor in
English, but unfortunately there's no way to teach them
how to think like a noncomputer person.

I suspect thet even the most extreme "noncomputer" person would agree that
the creation date of something is when it first came into being; ergo, the
creation date of a copy is the date it was copied.

The question is, what is that "something"? "Creation date" does not
tell you what the "something" is. Is it the creation date of the file
itself or the data in the file?

Suppose I have a nice, authentic Louis IV chair and I want another. I hire
someone to make it. He does an excellent job, the new chair is an exact
copy - in the most minute detail - of the original. Despite being an exact
copy, it is NOT a Louis IV chair, it is a copy and its creation date is when
it was made.

Agreed on the Louis IV chair. But that's not the same situation.

You're new chair will have new materials, new adhesives, new builder
(dare I say "creator"? LOL), etc. It is obviously not the original.

But that doesn't happen when you copy a computer file. The data in the
copied file is an *exact* copy, a clone, an identical twin. Your chair
is *not* an identical twin. The data does not change, only the labels
on the box. And the labels should not hint that the contents themselves
are somehow different.

___________________

John Doe is correct, there should be a way to tell, by
the date, which file is the actual, true original by
timestamp, and it should not be changed by the system.

There is. It is the "modified" date.

When you change the name of that information, you simply confuse the issue.

Which should be obvious from this discussion. G

If that is too difficult for our penantic Mr. Doe to use, he could prefix
the copied file with "Copy of file name". If that is too much trouble he
could copy the file into the same folder and MS will insert the prefix
itself.

And if John was "copying" a thousand files as a simple backup plan? G
Think about it, should the user actually have to do something that
pedantic on today's computers? BG


--
Ken

Mac OS X 10.8.5
Firefox 24.0
Thunderbird 17.0.8

On 11/26/13 7:03 AM, dadiOH wrote:
"John Doe" wrote in message

"dadiOH" dadiOH invalid.com wrote:

"John Doe" jdoe usenetlove.invalid wrote
Paul nospam needed.com wrote:
John Doe wrote:

File attributes: Date Last Saved 13/11/23 Date
Created 13/11/24 That's one thing Windows has
always done wrong and always will.

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

The creation date is obviously the oldest date
associated with the file. Why can't they maintain the
oldest date as the creation date? It's obviously a
major blunder that keeps going and going...

I'm surprised this isn't well-known. All you have to
do to prove it is copy a file from one folder to
another. The creation date changes to the copy date.
You might consider the copy date to be the creation
date but I certainly don't, and it destroys the real
creation date of the copied file. That totally messes
up backups if you ever need to use them, since they
are copies.

Or maybe the real creation date is maintained as one
of the other 15 or so different date properties?
Please advise.

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

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?

Everybody is getting lost/confused/focused on the words "creation date".
The problem with those two words, and those two words *only* is you
don't know which creation day you are talking about based on the screen
display. The creation date of the file, or the creation date of the
data. To most users, the creation date of the data is far more
important than the creation date of the file.


--
Ken

Mac OS X 10.8.5
Firefox 24.0
Thunderbird 17.0.8

In article , Gene E. Bloch
writes

It's not rocket science...

This is John Doe we're talking about. Don't waste the skin off your
fingertips replying to him.

--
(\_/)
(='.'=)
(")_(")

"Ken Springer" wrote in message

On 11/26/13 7:11 AM, dadiOH wrote:
"John Doe" wrote in message

"dadiOH" dadiOH invalid.com wrote:

"John Doe" jdoe usenetlove.invalid wrote
Grinder grinder no.spam.maam.com wrote:
John Doe wrote:

File attributes: Date Last Saved 13/11/23 Date
Created 13/11/24 That's one thing Windows has
always done wrong and always will.

My apologies if this has already been noted
elsewhere, but there is good reason for
CreationDate ModifyDate.

When a file is copied, the copy gets the current
date as a creation date, but the modification
date is copied from the original file.

Yeah, but what happened to the creation date? I
guess that programmers think computers are more
important than people. When
the file is copied, somehow the computer is
"creating" a file. And who cares when the human
being originally created the file...

There are so many file date attributes, you would
think that Microsoft could use one of them for
maintaining when the file was created. And it
would probably be called "date created". If you
want to have a "date copied", fine, but that's a
different attribute.

You have to wonder what they're thinking up there
in Redmond.

They're thinking that when you copy a file the date
it was copied is the
date it was created. They are right. A copied
file is a different entity
than the one from which it was copied.

Another idiotic answer...

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

A bit beneath you, dadiOH.

Just replying in kind...

--

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

On Tue, 26 Nov 2013 11:09:13 -0500, Zaphod Beeblebrox wrote:

On Mon, 25 Nov 2013 20:07:00 -0800, "Gene E. Bloch" not-
lid wrote in article da5fyvg6mt8t
...

On Mon, 25 Nov 2013 23:34:22 +0000, mechanic wrote:

On Mon, 25 Nov 2013 21:55:37 +0000 (UTC), John Doe wrote:

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

It *is* the date the file is created, when you copy a file you
create a file that's a duplicate of the original. What's so hard to
understand?

f/u set

For John Doe, the whole idea...

I think it is more thought in general that challenges it.

It has taken me several seconds to get here to type a reply and I'm
*still* laughing :-)

--
Gene E. Bloch (Stumbling Bloch)

On Tue, 26 Nov 2013 16:24:17 +0000, Mike Tomlinson wrote:

In article , Gene E. Bloch
writes

It's not rocket science...

This is John Doe we're talking about. Don't waste the skin off your
fingertips replying to him.

Heck, I'm having fun. Don't rain on my (meager) parade :-)

--
Gene E. Bloch (Stumbling Bloch)

Gene E. Bloch has written on 11/26/2013 1:51 PM:
On Tue, 26 Nov 2013 16:24:17 +0000, Mike Tomlinson wrote:

In article , Gene E. Bloch
writes

It's not rocket science...

This is John Doe we're talking about. Don't waste the skin off your
fingertips replying to him.

Heck, I'm having fun. Don't rain on my (meager) parade :-)

You need to get out more, Gene! :-0