使用 stat API 获取错误的文件修改时间 [英] Getting incorrect file modification time using stat APIs
问题描述
我在获取文件的修改时间时看到一个奇怪的行为.我们一直在调用 _stat64 方法来获取我们项目中的文件修改如下.
I see a strange behavior while fetching the modification time of a file. we have been calling _stat64 method to fetch the file modification in our project as following.
int my_win_stat( const char *path, struct _stati64 *buf)
{
if(_stati64( path, buf) == 0)
{
std::cout<<buf->st_mtime << std::endl; //I added to ensure if value is not changing elsewhere in the function.
}
...........
...........
}
当我使用 epoch convertor 转换 st_mtime 变量返回的纪元时间时，它显示 2:30 hrs在我的系统上设置的当前时间之前.
When I convert the epoch time returned by st_mtime variable using epoch convertor, it shows 2:30 hrs ahead of current time set on my system.
当我从不同的测试项目调用相同的 API 时，我看到了正确的 mtime(即根据我的系统显示的文件的 mtime).
When I call same API as following from different test project, I see the correct mtime (i.e. according to mtime of file shown by my system).
if (_stat64("D:\\engine_cost.frm", &buffer) == 0)
std::cout << buffer.st_mtime << std::endl;
即使我调用了 GetFileTime() 并在 this 帖子的帮助下将 FILETIME 转换为纪元时间.我根据系统设置的时间得到正确的时间.
Even I called GetFileTime() and converted FILETIME to epoch time with the help of this post. I get the correct time according to time set the system.
if (GetFileTime(hFile, &ftCreate, &ftAccess, &ftWrite))
{
ULARGE_INTEGER ull;
ull.LowPart = ftWrite.dwLowDateTime;
ull.HighPart = ftWrite.dwHighDateTime;
std::cout << (ull.QuadPart / 10000000ULL - 11644473600ULL);
}
我无法弄清楚的是，为什么通过我现有的项目调用时 mtime 的时间不同?
哪些参数会影响 mtime 的输出?
我还能尝试进一步调试问题吗?
What I am not able to figure out is why does the time mtime differ when called through my existing project?
What are the parameters that could affect the output of mtime ?
What else I could try to debug the problem further ?
- 在 VS2013 中，_stati64 是一个宏，被 _stat64 替换.
- Windows 7 上的文件系统是 NTFS.
推荐答案
一年后我遇到了类似的问题，但场景几乎没有什么不同.但这一次我明白为什么会有 +2:30 小时的差距.我通过 perl 脚本执行 C++ 程序，该脚本实习生设置时区 'GMT-3' 并且我的机器一直处于时区 'GMT+5:30'.因此，存在2:30Hrs"的差异.为什么 ?正如哈利在中提到的这个帖子
An year later I ran into the similar problem but scenario is little different. But this time I understand why there was a +2:30Hrs of gap. I execute the C++ program through a perl script which intern sets the timezone 'GMT-3' and my machine had been in timezone 'GMT+5:30'. As a result there was a difference of '2:30Hrs'.
Why ? As Harry mentioned in this post
更改 Perl 中的时区可能会导致设置 TZ 环境变量，从而影响 C 运行时库 根据 _tzset 的文档.
changing the timezone in Perl is probably causing the TZ environment variable to be set, which affects the C runtime library as per the documentation for _tzset.
这篇关于使用 stat API 获取错误的文件修改时间的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
