Microsoft's perennial incompetence...

"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's not rocket science...

Apparently it is, to some...

--









--
Gene E. Bloch (Stumbling Bloch)



Path: eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!feeder.erje.net!eu.feeder.erje.net!n ews-1.dfn.de!news.dfn.de!news.informatik.hu-berlin.de!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: Microsoft's perennial incompetence...
Date: Mon, 25 Nov 2013 11:46:57 -0800
Organization: Astrolabe
Lines: 55
Message-ID: 1iso4h7k45wuy$.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
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Trace: individual.net gnlofCVTZ72ZPSsXRM+JvgB49pnWr6qZ0sLHdRC3UPvx1AdxCS
Cancel-Lock: sha1:BKNlrGJqEFIHdsppj8pbp8BnnRM=
User-Agent: 40tude_Dialog/2.0.15.84
Xref: news.eternal-september.org alt.comp.hardware.pc-homebuilt:28835 alt.comp.os.windows-8:8243

In the last episode of , 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.

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

--
A fool and his money are soon popular.

Bull**** troll...

--
DevilsPGD boogabooga crazyhat.net wrote:

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

In the last episode of l70h0p$fc3$1 dont-email.me, John Doe
jdoe usenetlove.invalid said:

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.

--
A fool and his money are soon popular.

On 11/25/13 10:42 AM, Paul wrote:
John Doe wrote:
"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...


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

On 11/25/13 12:01 PM, John Doe wrote:
Paul nospam needed.com wrote:

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.

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

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.

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. Have all the other info there for the OS to use,
but leave that original date alone!

Someone mentioned using Metadata. But, what good is that data to the
average user? They don't even know it exists. And, do older files from
older OS versions even have that data?

IIRC, the windowing interfaces were supposed to mimic real life office
practices. In a paper filing system, you always have an easily
identifiable original file, all others should be marked as copies. And
there can be only one original file. Period. And you never destroy it!
Yet computer interfaces let you easily do this.

I'd think MS could easily change the vernacular of the file information,
to Original Created on DD/MM/YYYY (or similar), and any file that is
copied to another location could say Copy Created on DD/MM/YYYY. The
Original Created... is never, ever changed except by hacking, which you
can't prevent, AFAIK.

It could be some of this confusion is the result of technology
limitations of the time. I'm thinking screen resolution, where less
info could be displayed on the screen. IMO, that should not be a
consideration today, and we shouldn't be stepping back in time to
accommodate tablet/smart phone devices.

Grinder is correct, IMO, there should be the original date that tells
you something about the contents of the file, I.E. copied/modified, and
not where it's been copied or moved to for storage. If you are going to
access that date, you care about contents, not which drive it's on, not
whether it's the top drawer or the bottom drawer of the filing cabinet.

It seems Dave and I are on similar pages, here...
Do older .jpg files
even have EXIF data attached?

--
Ken

Mac OS X 10.8.5
Firefox 24.0
Thunderbird 17.0.8

On Mon, 25 Nov 2013 17:09:02 +0000 (UTC), John Doe wrote:

mechanic mechanic example.net wrote:

Grinder wrote:

Personally, I would prefer the creation date to remain intact
across a file copy, as it's more conformed to the idea that the
dates are about to contents of the file rather than the
container.

Just put the creation date in the file itself as a comment for
example, rather than rely on the OS to track it for you.

That's a ridiculous workaround.

why? It's the obvious way round this issue. It's under the control
of the user rather than the OS.

File meta-data is not designed for configuration management for
the user.

But seriously...

Microsoft's Windows Explorer recognizes over 400 file attributes.
Right-click on the columns bar and select More. And you're welcome
for the lesson.

What? We were talking about dates...and easy way to define the real
dates of creation or changes, and of content not of the file itself.
MS-Office provides some ways of defining change history in the
files, make use of it.

f/u set

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

On 2013-11-25, Ken Springer wrote:
On 11/25/13 12:01 PM, John Doe wrote:
Paul nospam needed.com wrote:

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.

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.


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?

generic name No-One in-the-sanitarium.invalid wrote:

On 2013-11-25, Ken Springer wordworks greeleynet.com wrote:
On 11/25/13 12:01 PM, John Doe wrote:
Paul nospam needed.com wrote:

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.

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.


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

--








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?



Path: eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: generic name No-One in-the-sanitarium.invalid
Newsgroups: alt.comp.hardware.pc-homebuilt,alt.comp.os.windows-8
Subject: Microsoft's perennial incompetence...
Date: Tue, 26 Nov 2013 02:23:30 +0000 (UTC)
Organization: A noiseless patient Spider
Lines: 51
Message-ID: l710n1$3io$1 dont-email.me
References: l6sjct$nro$2 dont-email.me OvOdnX7fV7vICA_PnZ2dnUVZ_sidnZ2d mchsi.com l6u5se$tcl$1 dont-email.me l6vga2$qnl$1 dont-email.me l6vuur$h19$3 dont-email.me l70274$bq6$1 dont-email.me l706pv$9us$1 dont-email.me l70krn$k3j$1 speranza.aioe.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Injection-Date: Tue, 26 Nov 2013 02:23:30 +0000 (UTC)
Injection-Info: mx05.eternal-september.org; posting-host="0c532a43752eed8b9326db4acde33be8"; logging-data="3672"; mail-complaints-to="abuse eternal-september.org"; posting-account="U2FsdGVkX1+8j7KJ4dBCPDlEFsqGUyS7"
User-Agent: slrn/0.9.9p1/mm/ao (Win32)
Cancel-Lock: sha1Lgxt33BXIZ0ZYYCrxIkxYzWwws=
Xref: news.eternal-september.org alt.comp.hardware.pc-homebuilt:28843 alt.comp.os.windows-8:8260

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

--
Gene E. Bloch (Stumbling Bloch)

On Mon, 25 Nov 2013 21:55:37 +0000 (UTC), John Doe 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.

Rather egregious non-sequitur...

It's not rocket science...

Apparently it is, to some...

Evidently...

--
Gene E. Bloch (Stumbling Bloch)

Pure bull****...

--
"Gene E. Bloch" not-me other.invalid wrote:

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

On Mon, 25 Nov 2013 21:55:37 +0000 (UTC), John Doe 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.

Rather egregious non-sequitur...

It's not rocket science...

Apparently it is, to some...

Evidently...

--
Gene E. Bloch (Stumbling Bloch)

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

--
"Gene E. Bloch" not-me other.invalid wrote:

Path: eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!feeder.erje.net!eu.feeder.erje.net!n ews.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: Microsoft's perennial incompetence...
Date: Mon, 25 Nov 2013 20:07:00 -0800
Organization: Astrolabe
Lines: 17
Message-ID: da5fyvg6mt8t$.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 1swid23go51ab$.dlg example1357.net
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Trace: individual.net hIOxCUfZruWZNOG9fQzeEANTYe1cALrStAT0cwqGSBk3i3WwwT
Cancel-Lock: sha1:lX/a85sZxAuIbJQduxJ0PPM4+X8=
User-Agent: 40tude_Dialog/2.0.15.84
Xref: news.eternal-september.org alt.comp.hardware.pc-homebuilt:28846 alt.comp.os.windows-8:8263

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

--
Gene E. Bloch (Stumbling Bloch)

On 11/25/13 7:23 PM, generic name wrote:
On 2013-11-25, Ken Springer wrote:
On 11/25/13 12:01 PM, John Doe wrote:
Paul nospam needed.com wrote:

snip

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