Bug in Windows Explorer Date of File not shown for old files

[Guest]

For my picture albums I am setting the dates of the particular files to the
date when the picture was taken. As I have pictures from the 1970ies I can
even set the the date with some public tools correctly. In the properties
view of the file the date appears correctly. With windows explorer in the
detail view there are no dates older than 1.1.1980 shown. The respective
field is just blanked. So I am not able to sort such files by date.

 

[Guest]

Sorry I have forgotten to ask a Question: Does anyone know about a fix of
this bug?

 

[Bob I]

1. Don't get your hopes up in this being changed.
2. Select another method of "dating" your pictures as the creation date
can get changed to the current date by some file operations.

 

[Bob I]

See reply to first posting.

Sorry I have forgotten to ask a Question: Does anyone know about a fix of
this bug?

:

 

[Guest]

Bob,

1. It is definitly a bug in Windows Explorer, so why do you presume it will
not be changed.

2. With my recent taken digital photos the creation date can be used, so
could you please tell me by which file operations the creation date will
change.

 

[Bob I]

1. The file creation date couldn't be prior to 1/1/1980 so therefor not
displaying something that can't exist can't be a "bug".

2. For a quick example download a file accross the internet, the result
will have the current time as the create date.

 

[Guest]

1. Your statement is valid for FAT32 volumes, but not for NTFS volumes. As
the file property shows the correct date prior to 1/1/1980 (on a NTFS volume)
and the list view in windows explorer doesnt show those dates, it is still a
bug of microsoft.

But meanwhile i found another product (see www.trackerv3.com) similar to
windows explorer. This file handling utility is handling those dates
correctly. It is even more flexible, as you can set the timestamps of a file
or a group of files as you like. It is really a shame for Microsoft.

 

[Bob I]

And since Microsoft is pushing people away from FAT32 to NTFS, the
"problem" is STILL not a problem. Really, a file creation date IS
intended to IDENTIFY the FILE CREATION DATE. The only shame is
attempting to create an issue out of a NON-ISSUE. The BUG is NOT a BUG.
The ISSUE is SOMEONE MIS-USING a FIELD and then COMPLAINING about the
RESULTS. Why not try putting "A.D." or "B.C." in the date created and
and call that a bug also when it doesn't work.

 

[David Candy]

When you create a file for the first time within an NT/Dos environment. Copying a file, moving doesn't matter as long as it stays within an operating system or MS network. If the file leaves the OS/Network then create date is lost. If it comes back in (like you emailed it) then it created anew.

 

[Guest]

Bob I, I don't want to put anything else like a regular date in this field.
So please don't discuss about A.D. and B.C. Further, as you mentioned, we
should restrict our disccussion to NTFS only.
Normal dates (even prior to 1/1/80) can be stored in the creation date field
and are show correctly in the File Properties (even with the correct
calculation of the day of the week). They are also show correctly in a CMD
box with the DIR comand. So if Windows Explorer is blanking out those dates
in its listed view, than it is of course a bug. According to my understanding
any inconsistency is a bug. Other products like TrackerV3 (see below) or the
CMD box of MICROSOFT, are consistent in that respect and have no bug.
Probably your definition of a bug is limited to blue screens.