当我将它们列为ls -l时,它们看起来非常正常@H_404_3@
-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 – 是可见的.@H_404_3@
我几乎被墙头撞到了试图理解为什么.我尝试了一些随机的东西,遇到了ls –full-time命令.它表明,这两者在某种程度上有点不同@H_404_3@
-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的？@H_404_3@
OS是最新更新的CentOS 5.5 Final,ls版本是(GNU coreutils)5.97@H_404_3@
另外,问题是我不明白文件的“时区”存储在何处. inode似乎没有任何额外的属性来存储它们.服务器上的FS是ext4.@H_404_3@
解决方法
find . -mtime 7
应该找到正好七天的文件(“七”表示在7.000和7.999天之间,给予或采取,“旧”表示“自上次修改以来”).如果您想要超过七天的文件(根据您的第一个文件(2010年6月)上的日期判断),请尝试@H_404_3@
find . -mtime +7
我同意你的看法时区很奇怪,但我认为这是可以解释的. man stat很清楚time_t是存储的,正如Sean R在下面所说的那样.我正在做的是将其显示为当地时间,并且当它这样做时,它足够友好地考虑当地的日光节约惯例.@H_404_3@
我的系统是相同的：发生在3月到10月的文件时间以0100时区显示,而在10月到3月下降的文件时间以0000时区显示,不是因为它存储在文件系统中而是因为时区文件告诉我的系统,在6月份,当我触摸文件时,我会在我认为是早上8点的时候完成它,而不是它将是早上7点 – 如果它是冬天.在展示恰好在夏天的时候,向我们展示它们在夏天会出现的情况,这就足够了,就是这样.@H_404_3@
如果你能在你的ls输出中找到任何时区,根据你们当地的惯例,这些时区不是夏天或冬天,那么我错了 – 但我在我的系统上找不到任何时区.@H_404_3@
