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.

On 11/24/2013 9:42 PM, John Doe wrote:
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.


Your argument makes much more sense now that you've capitalized it.

On 24 Nov 2013, Grinder wrote in
alt.comp.os.windows-8:

Your argument makes much more sense now that you've capitalized it.

If you feel you must interact with this clown, please try to remove the
gratuitous crossposted groups he added.

Poor little Nildo hasn't learned how to ignore a thread...

--
Nil rednoise REMOVETHIScomcast.net 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: Nil rednoise REMOVETHIScomcast.net
Newsgroups: alt.comp.hardware.pc-homebuilt,alt.comp.os.windows-8
Subject: Microsoft's perennial incompetence...
Date: Sun, 24 Nov 2013 23:10:23 -0500
Organization: (?!)
Lines: 7
Message-ID: XnsA282EBBAA385Cnilch1 wheedledeedle.moc
References: l6sjct$nro$2 dont-email.me OvOdnX7fV7vICA_PnZ2dnUVZ_sidnZ2d mchsi.com l6u5se$tcl$1 dont-email.me hcSdna1HbZBSKQ_PnZ2dnUVZ_sGdnZ2d mchsi.com l6ugvn$cmh$2 dont-email.me OPydnR7vWMVDVg_PnZ2dnUVZ_uWdnZ2d mchsi.com
X-Trace: individual.net XF7ZgZQT8Yym2KD9jOoPFgzwDrqvvT9XalBm2ZWEWd3UWD36ze
Cancel-Lock: sha1:ixmdyleVlRjDluofUewVJes/dzw=
User-Agent: Xnews/2006.08.24
X-Face: esm\a~e7BW-JD"t0\Ww_~\t!z_p0}xokJ"]a4/!ZtMGxQt_J`\IuTO++qOqVx0&Y.=z(B!:d?HNxL}yTuIS^5T8 W\iGv_s'oSFfLp%X|naUNr
Xref: news.eternal-september.org alt.comp.hardware.pc-homebuilt:28814 alt.comp.os.windows-8:8221

On 24 Nov 2013, Grinder grinder no.spam.maam.com wrote in
alt.comp.os.windows-8:

Your argument makes much more sense now that you've capitalized it.

If you feel you must interact with this clown, please try to remove the
gratuitous crossposted groups he added.

On Sun, 24 Nov 2013 21:24:57 -0500, David Trimboli wrote:

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.

Just to put this in a real-world perspective, I have been trying to help a
writer friend whose problem is that he has too many backups of all his
store of old files, some of which have been modified. He isn't terribly
technical and so I was trying to find a decent program to help him copy
and combine all his backups, putting the last-modified version into his
brand new computer. None of the "clever" backup programs (eg RoboCopy)
worked well enough to offer to him and he has started by copying
everything across and then trying to sort things manually.

Yesterday he rang me saying that because some musician had died he wanted
to contribute an old article he wrote about him for the magazine
"Downbeat" in the 80's to someone writing a book. He found the article OK
- all 8 copies.

It isn't easy to sort sensibly on dates.

"John Doe" wrote in message

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" of the original file becomes the
"modified date" of the copy.

--

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