Microsoft's perennial incompetence...

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.

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.

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.

Paul

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.

--








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.

Paul

On 11/24/2013 1:35 PM, Wolf Kirchmeir wrote:
On 2013-11-24 5:11 AM, 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.


Your clock is flaky.


At one time there was an internal rechargeable battery that keep parts
of the computer hot, When this battery died the first symptoms were time
discrepancies.

Does your computer have a battery, that should be replaced?

When, where, how, and if there is a battery is determined by the
manufacture, model, and type of the computer.

On 11/24/2013 4:11 AM, 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.

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.

On 11/24/2013 6:33 PM, John Doe 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.


It's obviously not your preference, but the mechanism, at it works, is
defensible. It's not incompetence on Microsoft's part, but rather your
disagreement with their definition for the attribute.

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. It doesn't really
make my underwear bunch up, though, as it is.

On 11/24/2013 7:33 PM, John Doe wrote:

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.

The date attributes are not there to tell *you* when the file's
*content* was created or modified; they're there to tell the *operating
system* when the *file* was created or modified, primarily for archiving
purposes.

--
David Trimboli
http://www.trimboli.name/

David Trimboli david trimboli.name wrote:

John Doe wrote:

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.

The date attributes are not there to tell *you* when the file's
*content* was created or modified; they're there to tell the
*operating system* when the *file* was created or modified,
primarily for archiving purposes.

If that *were* true, then they wouldn't be selectable in *Windows
Explorer columns*. But *in fact* they are listed along with
*hundreds of other file attributes* that are obviously for the
user. Yes, Microsoft is too *lazy* to clean up its *obsolete* and
*misnamed* file attributes. But *knowing* when I started a file is
more *useful* than *95%* of the other *400+* attributes
*Microsoft* has *decided* to *recognize*. *Microsoft* is too
*lazy* to *add* such *useful* code to *Windows Explorer*, even
*though* *it* *already* *records* *the* *original* *creation*
*date*. *Instead*, *we* *have* *a* *misleading* *file* *attribute*
"meant for the operating system".








snipped spam signature, typically accompanying a bull**** answer



--
Path: eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: David Trimboli david trimboli.name
Newsgroups: alt.comp.hardware.pc-homebuilt,alt.comp.os.windows-8
Subject: Microsoft's perennial incompetence...
Date: Sun, 24 Nov 2013 21:24:57 -0500
Organization: A noiseless patient Spider
Lines: 15
Message-ID: l6ucdq$qng$1 dont-email.me
References: l6sjct$nro$2 dont-email.me OvOdnX7fV7vICA_PnZ2dnUVZ_sidnZ2d mchsi.com l6u5se$tcl$1 dont-email.me
Reply-To: david trimboli.name
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 25 Nov 2013 02:24:59 +0000 (UTC)
Injection-Info: mx05.eternal-september.org; posting-host="509f64ee5d18779693bd0889dfcf0fda"; logging-data="27376"; mail-complaints-to="abuse eternal-september.org"; posting-account="U2FsdGVkX1/4kyjmWHmVtydlKE80FrXibHqoB4u7FWs="
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
In-Reply-To: l6u5se$tcl$1 dont-email.me
Cancel-Lock: sha1:TG0Fpw/dqfvWi43yd8QJOU1IhOY=
Xref: news.eternal-september.org alt.comp.hardware.pc-homebuilt:28810 alt.comp.os.windows-8:8217

IT DOESN'T MAKE MY UNDERWEAR BUNCH UP EITHER, IT'S JUST ONE OF
DOZENS OF IDIOTIC IN-YOUR-FACE THINGS WINDOWS DOES THAT SHOWS HOW
INCOMPETENT/LAZY/WHATEVER MICROSOFT IS. IT'S JUST ONE OF SO MANY
CONSTANT REMINDERS THAT MICROSOFT ISN'T A GENUINE HIGH TECHNOLOGY
COMPANY AND THAT THEY COULDN'T CARE LESS ABOUT ANYTHING EXCEPT
THEIR MONOPOLY POWER.

--
Grinder grinder no.spam.maam.com wrote:

Path: eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!news.glorb.com!border3.nntp.dca.giga news.com!Xl.tags.giganews.com!border1.nntp.dca.gig anews.com!nntp.giganews.com!local2.nntp.dca.gigane ws.com!nntp.mchsi.com!news.mchsi.com.POSTED!not-for-mail
NNTP-Posting-Date: Sun, 24 Nov 2013 20:24:15 -0600
Date: Sun, 24 Nov 2013 20:23:15 -0600
From: Grinder grinder no.spam.maam.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
Newsgroups: alt.comp.hardware.pc-homebuilt,alt.comp.os.windows-8
Subject: Microsoft's perennial incompetence...
References: l6sjct$nro$2 dont-email.me OvOdnX7fV7vICA_PnZ2dnUVZ_sidnZ2d mchsi.com l6u5se$tcl$1 dont-email.me
In-Reply-To: l6u5se$tcl$1 dont-email.me
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: hcSdna1HbZBSKQ_PnZ2dnUVZ_sGdnZ2d mchsi.com
Lines: 38
X-Usenet-Provider: http://www.giganews.com
NNTP-Posting-Host: 50.81.108.157
X-Trace: sv3-0wDVZJ7JJH6Cg3DKcAqMyKKXIdMtWX1HknGWQQZmQd7Hlt0xBD d/2xE+A1epain3wlV5Sq+ortWQl+/!fxQxdY4fBaSZrnFtahO3hv/r1Fs2T4ofaXHiJTjGOkKjDPWmOmQUC4dp9LPXk6SNzc2h0EwVI NKo!bpWtQDE=
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 2824
Xref: news.eternal-september.org alt.comp.hardware.pc-homebuilt:28809 alt.comp.os.windows-8:8216

On 11/24/2013 6:33 PM, John Doe 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.


It's obviously not your preference, but the mechanism, at it works, is
defensible. It's not incompetence on Microsoft's part, but rather your
disagreement with their definition for the attribute.

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. It doesn't really
make my underwear bunch up, though, as it is.