linux – “find -mtime”在具有不同时区的文件上无法正常工作?

前端之家收集整理的这篇文章主要介绍了linux – “find -mtime”在具有不同时区的文件上无法正常工作?前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
我在几个月前的服务器上有一些日期的文件,但是对于find -mtime 7搜索是不可见的.

当我将它们列为ls -l时,它们看起来非常正常

-rw-r--r-- 1 root root    347253 Jun 12 16:26 pedia_main.2010-06-12-04-25-02.sql.gz
-rw-r--r-- 1 root root 490144578 Nov 24 16:26 gsmforum_main.2010-11-24-04-25-02.sql.gz

顶部文件对于“find.-mtime 1”是不可见的,但是botton one – 是可见的.

我几乎被墙头撞到了试图理解为什么.我尝试了一些随机的东西,遇到了ls –full-time命令.它表明,这两者在某种程度上有点不同

-rw-r--r-- 1 root root    347253 2010-06-12 16:26:20.000000000 +0400 pedia_main.2010-06-12-04-25-02.sql.gz
-rw-r--r-- 1 root root 490144578 2010-11-24 16:26:12.000000000 +0300 gsmforum_main.2010-11-24-04-25-02.sql.gz

日期似乎没问题,第一位有0400作为时区,另一位是0300.为什么找不到找到0400的?

OS是最新更新的CentOS 5.5 Final,ls版本是(GNU coreutils)5.97

另外,问题是我不明白文件的“时区”存储在何处. inode似乎没有任何额外的属性来存储它们.服务器上的FS是ext4.

解决方法

timzeone问题可能是红鲱鱼.
find . -mtime 7

应该找到正好七天的文件(“七”表示在7.000和7.999天之间,给予或采取,“旧”表示“自上次修改以来”).如果您想要超过七天的文件(根据您的第一个文件(2010年6月)上的日期判断),请尝试

find . -mtime +7

我同意你的看法时区很奇怪,但我认为这是可以解释的. man stat很清楚time_t是存储的,正如Sean R在下面所说的那样.我正在做的是将其显示为当地时间,并且当它这样做时,它足够友好地考虑当地的日光节约惯例.

我的系统是相同的:发生在3月到10月的文件时间以0100时区显示,而在10月到3月下降的文件时间以0000时区显示,不是因为它存储在文件系统中而是因为时区文件告诉我的系统,在6月份,当我触摸文件时,我会在我认为是早上8点的时候完成它,而不是它将是早上7点 – 如果它是冬天.在展示恰好在夏天的时候,向我们展示它们在夏天会出现的情况,这就足够了,就是这样.

如果你能在你的ls输出中找到任何时区,根据你们当地的惯例,这些时区不是夏天或冬天,那么我错了 – 但我在我的系统上找不到任何时区.

猜你在找的Linux相关文章