I have one mistake .Why I dont know I want to take this file last modified date .but I have problem
in my code : date is coming always 01011601 why?Do you have any suggestions ?
I have one mistake .Why I dont know I want to take this file last modified date .but I have problem
in my code : date is coming always 01011601 why?Do you have any suggestions ?
If the path you're getting your files from (pthh
) is not the directory your app is running in, I would expect this date.
When you're calling File.GetLastWriteTime(sqzfiles[i])
you are now relying on only the file name, so relative pathing is being used. Most likely, that file is not in your app's directory (although it is in pthh
).
Since the file at the relative path does not exist, the documentation will explain your unexpected date:
If the file described in the path parameter does not exist, this method returns 12:00 midnight, January 1, 1601 A.D. (C.E.) Coordinated Universal Time (UTC), adjusted to local time.
I've also seen this happen if the file is locked by another application, for what it's worth.
From msdn
If the file described in the path parameter does not exist, this method returns 12:00 midnight, January 1, 1601 A.D. (C.E.) Coordinated Universal Time (UTC), adjusted to local time.
https://msdn.microsoft.com/en-US/library/system.io.file.getlastwritetime(v=vs.110).aspx
I guess your file is not found. Try to specify the full path of the file
Does the file definitely exist when you try to access the write time?
The documentation has the following remark:
If the file described in the path parameter does not exist, this method returns 12:00 midnight, January 1, 1601 A.D. (C.E.) Coordinated Universal Time (UTC), adjusted to local time.
In this case it appears that your path may be invalid. See MSDN documentation:
You can identify the source of the problem by creating a small test application (i.e. a sandbox) to verify that your code is working as expected. To minimize potential errors, make the test as simple as possible (e.g. use hard coded file path).
GetLastWriteTime(...)
method does not always work as expected. In certain situations, the method will not return an updated time-stamp even though the file has been modified/changed. This scenario is related to: