浏览 7900 次
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
---|---|
作者 | 正文 |
发表时间:2007-03-03
但在linux上就时不时case会fail. 即两次生成的文件的timestamp相同了. 跟踪code发现确实做了写class文件这个动作. 也就是说jsp compiler的逻辑没问题. 于是做了这么一个实验 java 代码
这个程序在Windows下能一直运行下去, 就是说两次文件的lastmodify的timestamp不同, 但在linux下则很快就停下来了. 但如果把那个Thread.sleep改成3000的话, 就可以一直run了. 开始觉得是文件没有flush, 但加了flush也没有改变. 看来问题是在sleep上, 也许是因为在linux上, java的Thread.sleep太不精确, 而这个写文件操作也比较快, 所以就没怎么sleep就进行了第二次文件写操作, 从而使两次timestamp相同. 但这个不好验证. 还不能确定是否根本原因. 声明:ITeye文章版权属于作者,受法律保护。没有作者书面许可不得转载。
推荐链接
|
|
返回顶楼 | |
发表时间:2007-03-03
文件系统记录文件访问时间一般都不是精确到毫秒的, 在原始的zip打包中甚至文件时间是两秒的整倍数.
这个问题很可能是 ext2 和 NTFS 文件系统的差别. |
|
返回顶楼 | |
发表时间:2007-03-03
在windows中也不是一直运行的,如文件系统为FAT32则t1==t2,如果为NTFS才能一直运行,why?
|
|
返回顶楼 | |
发表时间:2007-03-04
zip打包有两秒的的误差, 是因为打zip包的函数有bug.
|
|
返回顶楼 | |
发表时间:2007-03-04
你可以把 File.lastModified(); 的返回值在不同文件系统上统计一下, 看看是不是都是一个单位时间的整倍数.
|
|
返回顶楼 | |
发表时间:2007-03-04
最后查了一下,确实应该是跟文件系统有关系.
在SUN的JDK bug 4697792上说明了这个情况: Without having a good reference source: FAT12, FAT16, and FAT32 file systems have a 2 second file time resolution. NTFS has a 100 nanosecond file time resolution. Unix/Linux has a 1 second file time resolution. So - depending on the underlying system, the values will either be accurate to the millisecond (NTFS) or rounded to the nearest 2 second (FAT32). 不过这也不能完全说是SUN JDK的bug,应该是SUN DOC上的bug,没有把这个limitation明确说明. |
|
返回顶楼 | |
发表时间:2007-03-05
哦,涨知识了!
|
|
返回顶楼 | |