Skip to content

Detecting that a file is not found or has no appropriate date information #1415

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
rpetrusha opened this issue Feb 23, 2018 · 2 comments
Open
Labels
area-System.IO Pri2 Indicates issues/PRs that are medium priority Pri3 Indicates issues/PRs that are low priority
Milestone

Comments

@rpetrusha
Copy link

Detecting that a file is not found or has no appropriate date information

General

The following methods all return 12:00:00.00000 January 1, 1601 as the date if the file represented by a FileSystemInfo object does not exit or if the operating system cannot supply the requested information:

  • FileSystemInfo.CreationTime
  • FileSystemInfo.CreationTimeUtc
  • FileSystemInfo.LastWriteTime
  • FileSystemInfo.LastWriteTimeUtc

In PR #4453, @BillWagner raised the question of how to detect this missing/incomplete information -- whether there's a constant available, or whether the returned date should be compared with some date. Since the .NET Framework does not include a predefined constant for this purpose, detection requires comparison with a specific date. The best alternative is probably to implement a utility method that converts the returned date back to UTC and tests whether the result is less than or equal to 12:00:00.00000 January 1, 1601. It's also possible to avoid the UTC conversion and simply pick some arbitrary date after that, since presumably no file should legitimately have a creation/last write time in the seventeenth century.

//cc @BillWagner @JeremyKuhne

@rpetrusha rpetrusha self-assigned this Feb 23, 2018
@JeremyKuhne
Copy link
Member

JeremyKuhne commented Feb 23, 2018

When we can't determine a value it is returned as .FromFileTime(0). You can actually have time stamps of this value on Windows. Unix times, however don't go back before 1970-01-01 00:00:00 +0000 (UTC).

@mairaw
Copy link
Contributor

mairaw commented Jun 18, 2018

Lowered the priority during triage,

@rpetrusha rpetrusha transferred this issue from dotnet/docs Dec 17, 2018
@dotnet-bot dotnet-bot added the untriaged New issue has not been triaged by the area owner label Dec 17, 2018
@rpetrusha rpetrusha added Pri2 Indicates issues/PRs that are medium priority 📁 Repo - dotnet-api-docs and removed untriaged New issue has not been triaged by the area owner labels Dec 17, 2018
@rpetrusha rpetrusha modified the milestones: February 2019, March 2019 Feb 25, 2019
@rpetrusha rpetrusha modified the milestones: March 2019, April 2019 Apr 1, 2019
@rpetrusha rpetrusha modified the milestones: April 2019, May 2019 Apr 29, 2019
@rpetrusha rpetrusha modified the milestones: May 2019, June 2019 Jun 4, 2019
@rpetrusha rpetrusha modified the milestones: June 2019, July 2019 Jul 1, 2019
@rpetrusha rpetrusha modified the milestones: July 2019, August 2019 Jul 26, 2019
@rpetrusha rpetrusha modified the milestones: August 2019, October 2019 Sep 9, 2019
@rpetrusha rpetrusha modified the milestones: October 2019, Backlog Oct 11, 2019
@rpetrusha rpetrusha removed their assignment Oct 11, 2019
@PRMerger13 PRMerger13 added the Pri3 Indicates issues/PRs that are low priority label Nov 11, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-System.IO Pri2 Indicates issues/PRs that are medium priority Pri3 Indicates issues/PRs that are low priority
Projects
None yet
Development

No branches or pull requests

7 participants