[文件操作] [讨论]dir /od 果真是按照时间排序的么？

namejm

在dir的帮助信息中，对参数 /OD 的解释是： 按日期/时间(从先到后)
果真如此？
我们来做个试验：

@echo off
for /l %%i in (1,1,300) do cd.>%%i.txt
dir /a-d /b /od *.txt
pause
复制代码

结果截图：

谁能看出这些文件到底是按什么顺序排列的？
别问我
我也不知道

看了一下各位的回帖
貌似各个系统之间有所差别
补充一下我的测试环境：
WindowsXP_Pro_SP3，简体中文版

或许这是dir的一个bug
可能到了Win7下被修复了
一如N年前在XP_SP2下用 reg querry 查询含中文字符的字符串会被“吃掉”部分字符，到了XP_SP3下已经被修复了一样

qzwqzw

54# fastslz
NTFS可以精确到100000毫秒以内
可能是描述性错误
NTFS的创建时间可以精确到0.000001毫秒

wmic的结果说明不了太多的问题
只能说明ntfs的文件是成批的flush的
而且wmic的CreationDate还出现了错误
在删除文件后重新创建该文件
该文件的CreationDate显示的还是上一次创建时间
测试代码如下：

@echo off
for /l %%i in (1,1,30) do echo.A>%%i.xxx
Wmic Datafile Where "Extension='xxx' and Drive='d:' and Path='\\Test\\temp\\'" get CreationDate,name /format:htable:"sortby=CreationDate"> batfile.html
del *.xxx
for /l %%i in (1,1,30) do echo.A>%%i.xxx
Wmic Datafile Where "Extension='xxx' and Drive='d:' and Path='\\Test\\temp\\'" get CreationDate,name /format:htable:"sortby=CreationDate">> batfile.html
del *.xxx
start batfile.html
复制代码

现在已经大致有了NTFS写入文件的轮廓
文件句柄的创建与关闭肯定是顺序的
文件首先写入到缓存（可能是内存或虚拟内存）中
缓存上的文件数据块受缓存管理器管理
无论NTFS、FAT32还是exFAT都是统一的缓存管理器
NTFS卷上的文件更新时需要先更新日志文件
以便于数据文件写入失败时可以继续或者撤销
在日志文件写入物理存储之前
数据文件被缓存管理器定义为不可写NO WRITE状态
而日志文件的写入时机是受缓存管理器约束的
为了提高IO性能
缓存管理器对数据文件和日志文件的管理是多线程并发的
而受到Windows核心对CPU资源的管理策略影响
并发线程的执行顺序有一定的随机性
所以数据文件的实际写入顺序存在一定的随机性

fastslz

NTFS 维基百科写的更全面一些
NTFS可以精确到100000毫秒以内（其实没那么精确）
+480取决于文件创建时系统当前设置的时区，而当前时区可以是动态的，如果这个文件拿到不同时区的电脑上，加减480值来获取相应当前系统时区的文件创建时间

fastslz

用wmi获取的文件写入时间FAT32,exFAT可以精确到100毫秒以内，NTFS可以精确到100000毫秒以内，应该是这些信息决定了它的排列方式
我这里xp和Windows7排列方式一样的，所以不应该存在BUG
每台电脑排列方式不一样可以这样解释，比如用for创建300个文件奔3级CPU创建可能所需时间更长

@echo off
:测试方法放在不同文件系统的根目录下
set adir=%~d0
ver|find "5.1"&&set v=5.1
ver|find "6.1"&&set v=6.1

if defined v (
md %adir%\%v%-Test 2>nul
if not exist %adir%\%v%-Test\*.txt for /l %%i in (1,1,300) do cd.>%adir%\%v%-Test\%%i.txt
)

for %%i in (5.1,6.1) do (
if exist %adir%\%%i-Test\*.txt (
Wmic Datafile Where "Extension='txt' and Drive='%adir%' and path='\\%%i-Test\\'" get CreationDate,name>%%i-Test-%v%-wmi.txt
dir /a-d /b /od    %adir%\%%i-Test\*.txt>%%i-Test-%v%-od.txt
))
复制代码

引用NTFS百度百科

对DOS略知一二的读者一定熟悉文件的各种属性:只读、隐藏、系统等。在NTFS文件系统中，这些属性都还存在，但有了很大不同。在这里，一切东西都是一种属性，就连文件内容也是一种属性。这些属性的列表不是固定的，可以随时增加，这也就是为什么你会在NTFS分区上看到文件有更多的属性. 　　
NTFS文件系统中的文件属性可以分成两种:常驻属性和非常驻属性，常驻属性直接保存在MFT中，像文件名和相关时间信息(例如创建时间、修改时间等)永远属于常驻属性，非常驻属性则保存在MFT之外，但会使用一种复杂的索引方式来进行指示。如果文件或文件夹小于1500字节(其实我们的电脑中有相当多这样大小的文件或文件夹)，那么它们的所有属性，包括内容都会常驻在MFT中，而MFT是Windows一启动就会载入到内存中的，这样当你查看这些文件或文件夹时，其实它们的内容早已在缓存中了，自然大大提高了文件和文件夹的访问速度。

NTFS   20110524103722.675442+480  1.txt
FAT32 20110524103651.520000+***  1.txt
480包含了时区，表示相对于UTC的时差分钟数，中国是第八时区，相差480分钟

qzwqzw

51# plp626
辞不达意
看不出跟上下文有什么关联

plp626

fastlz说，wmi 。。。。

一针见血。。。

mxxcgzxxx

要想有结论看来要去专业硬件论坛咨询了！

michael8111

48# zm900612


还有“推测”二字……
目前还无法证明：NTFS是否会导致文件的存储顺序随机化

CrLf

46# zm900612
已经试验证实文件逻辑存储顺序与文件系统有关
对一个磁盘分区先后格式化为NTFS、FAT32、exFAT三种FS格式
拷入以下脚本文件反复测试文件逻辑存储的偏移
结果发现在同一台PC上
NTFS总是具有明显的 ...
qzwqzw 发表于 2011-5-20 10:56

看来有结论了，嘿嘿

qzwqzw

46# zm900612
已经试验证实文件逻辑存储顺序与文件系统有关
对一个磁盘分区先后格式化为NTFS、FAT32、exFAT三种FS格式
拷入以下脚本文件反复测试文件逻辑存储的偏移
结果发现在同一台PC上
NTFS总是具有明显的偏移
FAT32和exFAT则几乎没有
另外发现NTFS下文件写入的速度的明显快于FAT32/exFAT
推测正因为NTFS采取了更为高效的缓存机制
所以一方面导致文件读写性能大幅提升
另一方面导致文件的逻辑存储顺序随机化

@echo off & setlocal EnableDelayedExpansion
for /l %%i in (1,1,300) do echo.A>%%i.xxx
set maxoffset=0
set minoffset=0
for /f %%f in ('dir /a-d /b /od *.xxx') do (
	set/p=%%f <nul
	set /a count+=1
	set /a offset=%%~nf-count
	if !offset! gtr !maxoffset! set maxoffset=!offset!
	if !offset! lss !minoffset! set minoffset=!offset!
)
echo.
echo ----------- %minoffset% : %maxoffset% -----------------
pause
del *.xxx
复制代码

CrLf

45# Batcher


！！磁盘缓存...

Batcher

44# qzwqzw


由于磁盘缓存的存在，我很好奇它到底是不是依次逐一写磁盘的。有没有详细的资料可供参考？

qzwqzw

42# michael8111
“比较”以及“理想”都是一个模糊的词
需要一个量化的指标来进行标定
可能需要一个脚本

另外修改时间确实是秒级
这是文件存储的数据结构所决定的
dir不可能会检查到低于秒级的单位
这种情况只可能是因为有足够的时间缓冲
文件得以按顺序逐一flush到磁盘中
所以dir才能按照创建顺序展示

mxxcgzxxx

41# qzwqzw

我想了很久，比较倾向于41楼的说法
有可能是缓存造成的写入延时或别的什么顺序错误

michael8111

但是如果“逻辑存储顺序”出现倒序 那就应该与IO无关了
我在磁盘没有显著IO任务，且IO性能“比较”好的情况下 做了100组实验数据 结果都是乱序
我贴出一部分 证明dir的顺序在“理想”的磁盘环境中也会是乱的：

80.txt
82.txt
81.txt
83.txt
86.txt
87.txt
84.txt
88.txt
85.txt
94.txt
92.txt
93.txt
91.txt
89.txt
90.txt
96.txt
97.txt
98.txt
100.txt
95.txt
99.txt
复制代码

另外：
ping -n 1 127.1>nul
这条命令的执行时间只有大约半秒
然而如果每隔这个时间间隔创建一个文件 那么dir的顺序就是标准的
也就是说 dir的修改时间应该比秒精确一点