grldr无法识别SSD盘上经碎片整理后的文件？

emutemp · 发表于 2014-4-27 16:47:23

本帖最后由 emutemp 于 2014-4-27 16:54 编辑

120G的SSD盘，放一个有碎片的2G的磁盘镜像文件。
未碎片整理前，grldr可以读取并map --mem；
用wcontig碎片整理后，grldr用cat和map的文件名自动补齐功能可以列表出该文件，但对该文件执行cat --hex或map --mem时，显示“ERROR15,:File not found”。

该文件在windows下显示是连续文件，并可以正常的读取和操作，唯独在grldr中只能列表出文件名，无法读取。
试过grldr（0.45C）20111206版，20140117版，以及2011yaya2007777出的碎片仿真（0.46a）20140419版，都是同样的情况。

目前只发现在SSD盘上有这种问题，之前在机械盘上wcontig整理后读取一切正常。

huaqingyuan · 发表于 2015-1-6 21:43:12

SSD不同于机械硬盘，不建议做整理！

emutemp · 发表于 2014-9-6 17:57:09

终于有条件测试了。

附件已测试，可以读取文件了，幸苦了！感谢！

同时测试了20140905的版本，046a版可以读取，045c版无法读取。
是不是只有046a版打了这个补丁？

emutemp · 发表于 2014-5-23 15:43:51

幸苦2011yaya2007777了。
现在在外地出差，没有原环境，可能要等到回去才能测试了。

2011yaya2007777 · 发表于 2014-5-20 17:06:47

分区格式化工具不能确定了，可能是U盘启动的DOS环境下用disk genius分区格式化的。

请 emutemp 在原环境测试，是否可以支持大于 4Kb 的非常驻属性列表，即可执行 cat --hex ？

emutemp · 发表于 2014-5-6 14:32:53

本帖最后由 emutemp 于 2014-5-6 14:34 编辑

2011yaya2007777 发表于 2014-5-6 10:13
如下重复，直至不一样为止。
80 00 00 00 20 00 00 1a - xx xx xx xx xx xx xx xx
xx xx xx xx xx xx x ...

分区格式化工具不能确定了，可能是U盘启动的DOS环境下用disk genius分区格式化的。
Vram2k32g.dsk应该是在winxp下，用FlashFXP的FTP下载方式复制过来的，之后用wcontig 120b版整理成连续文件。

4处的截图。

2011yaya2007777 · 发表于 2014-5-6 10:13:12

本帖最后由 2011yaya2007777 于 2014-5-6 10:48 编辑

挺长的，不知如何判断结尾。可能是4K字节。

如下重复，直至不一样为止。
80 00 00 00 20 00 00 1a - xx xx xx xx xx xx xx xx
xx xx xx xx xx xx xx xx - xx xx xx xx xx xx xx xx

请把 89cdf000 和 059295a000 结束处的前后10几行截图。
请把 c46e8800 和 c4524400 像以前 FILE0.jpg 一样截图。

120G的SSD盘，是在什么环境下（windows 或其他）格式化为 NTFS 格式的？
Vram2k32g.dsk 是是在什么环境下，使用什么工具复制进来的？

2011yaya2007777 · 发表于 2014-5-5 18:54:21

那就算了。辛苦了。

emutemp · 发表于 2014-5-5 17:31:56

2011yaya2007777 发表于 2014-5-5 17:01
方法可以，但是一定要从逻辑磁盘E打开，不要从物理磁盘分区打开，容易出错。
属性列表还真没见过。不好说 ...

前面几行从ASCII码内容上看，是其它文件的内容。

挺长的，不知如何判断结尾。可能是4K字节。

2011yaya2007777 · 发表于 2014-5-5 17:01:55

方法可以，但是一定要从逻辑磁盘E打开，不要从物理磁盘分区打开，容易出错。
属性列表还真没见过。不好说截对没有。最好将0x89CDF000前面几行也选上，他有多少字节？不长的话，截一个完整的，

emutemp · 发表于 2014-5-5 16:21:23

该分区每簇8个扇区，winhex有相对偏移定位功能，用相对偏移定位：
（0x89cdf×8+0）×0x200=0x89CDF000（该分区的相对偏移位置）
（0x59295a×8+0）×0x200=0x59295A000（该分区的相对偏移位置）

这样截是否正确？

2011yaya2007777 · 发表于 2014-5-3 10:25:55

文件记录结构比较复杂。有 2 个属性记录，分别位于逻辑簇号 0x89cdf 和 0x59295a 处。
（逻辑簇号*每簇扇区数 + 分区起始扇区）*0x200 可以定位到属性记录在磁盘的字节。
请把这 2 个属性记录截图打包上来。

emutemp · 发表于 2014-5-2 22:55:44

本帖最后由 emutemp 于 2014-5-2 23:10 编辑

2011yaya2007777 发表于 2014-5-2 17:55
每张图需从头开始截图，一般有 INDX 或 FILE0 字样，长度一般为 1 kb 。

之上的图1和2是在同一个INDX段里，重新一起截了张INDX图。文件名出现的两处分别在：0BD799660，0BD799EA0行。
之上的图3是在FILE0段里，重新截了张FILE0图。文件名出现在：0C45241B0行。

2011yaya2007777 · 发表于 2014-5-2 17:55:28

每张图需从头开始截图，一般有 INDX 或 FILE0 字样，长度一般为 1 kb 。

mfkwgij · 发表于 2014-5-2 17:43:24

有图放上来看以西阿里！~

emutemp · 发表于 2014-5-2 15:45:57

2011yaya2007777 发表于 2014-5-2 07:09
不是。用 winhex 打开磁盘，使用 16 进制搜索（不区分大小写），输入文件名。比如文件名是 Abc，则按小写 ...

文件名是：Vram2k32g.dsk
使用全小写“vram2k32g”转换的16进制数“7600720061006D0032006B00330032006700”搜索，找不到任何数据；
使用与文件名一致的“Vram2k32g”(V大写)转换的16进制数“5600720061006D0032006B00330032006700”搜索，找到3个匹配数据。

2011yaya2007777 · 发表于 2014-5-2 07:09:46

本帖最后由 2011yaya2007777 于 2014-5-2 07:21 编辑

含有该文件的目录截图?
是这样吗？

不是。用 winhex 打开磁盘，使用 16 进制搜索（不区分大小写），输入文件名。比如文件名是 Abc，则按小写输入 610062006300。
所有能找到的地方截图，打包上来。

emutemp · 发表于 2014-5-2 02:10:03

本帖最后由 emutemp 于 2014-5-2 02:15 编辑

2011yaya2007777 发表于 2014-5-1 16:23
我感觉是 wcontig 产生的问题。没有按规范删除原文件目录，致使 G4D 首先找到并使用该目录。但由于 Don't s ...

含有该文件的目录截图?
是这样吗？

屏幕分辨率的关系，最左边的1个字符只显示了一半，不过应该不影响理解。

图中，blocklist命令后用自动补齐功能，能列表出文件Vram2k32g.dsk，但是对该文件执行操作时ERROR15.
之前用cat,map都是一样的结果。

2011yaya2007777 · 发表于 2014-5-1 16:23:29

我感觉是 wcontig 产生的问题。没有按规范删除原文件目录，致使 G4D 首先找到并使用该目录。但由于 Don't support >4K ，所以拒绝执行。
也许是 G4D 或略了文件删除标记，没有继续寻找下一文件目录？可能性不大。

请楼主把含有该文件的目录截图贴上来，分析一下。

不点 · 发表于 2014-4-28 17:31:30

Non-resident attribute list too large

这条消息与 bean 的 NTFS 驱动程序的如下注释吻合（文件名 fsys_ntfs.c）：

* 3. Don't support >4K non-resident attribute list and $BITMAP

这是这个驱动程序的限制，要么你自己尝试修改，要么等待 bean 等人来改进。

我觉得可能算是某些软件生成的文件超出了常规。也就是说，产生了不正常的文件，以至于 bean 觉得它们属于异常情况，不予支持。

请尝试换用别的方式来生成文件，躲过这些限制条件。

emutemp · 发表于 2014-4-28 16:33:47

本帖最后由 emutemp 于 2014-4-28 16:35 编辑

使用debug on，没特殊的调试输出，还是仅显示ERROR15,File not found;

使用debug 0xffffffff，ERROR15前多输出两行信息，
Non-resident attribute list too large
No $DATA in MFT 0x11490

ERROR15,File not found

不点 · 发表于 2014-4-28 05:43:35

你自己可以设置 debug on 或 debug 0xFFFFFFFF 打开调试输出，看看会出现什么错误。甚至你也可以修改源代码，增加输出信息，确定出错的地方。

emutemp · 发表于 2014-4-27 23:47:15

本帖最后由 emutemp 于 2014-4-27 23:49 编辑

未压缩。

最奇怪的是GRLDR能列表出这个文件，但是操作文件时就找不到，还不是读取出错，是File not found。

jack95 · 发表于 2014-4-27 23:17:07

ntfs是否设置了压缩？'

不点 · 发表于 2014-4-27 22:08:49

ntfs 文件系统驱动程序的问题，很难解决。需要有人懂得 ntfs 文件系统规范才行。很难找这样的开发者了，尤其是在目前大洗牌、大变局的形势下。

emutemp · 发表于 2014-4-27 22:02:35

只是解决倒是有办法，只要把文件拷到其它分区再拷回来就可以了。

想着能找出个这个问题的所在和彻底的解决方法，完善grldr就更好了。

不点 · 发表于 2014-4-27 21:13:54

把碎片整理后的文件改名为别的任意文件名，比如改成 3.dsk，看看有没有效果？如果不行，那估计你只好格式化然后重做了，或者干脆做成 fat32 格式。

emutemp · 发表于 2014-4-27 21:07:34

文件名大小写试过了，无论都改成大写还是都改成小写，都一样的效果。

不点 · 发表于 2014-4-27 21:03:27

我注意到两个文件名的第一个字母的大小写不一样。也许是这个细节造成的？

你改名以后再试试，看问题是否消失？我是说，干脆改成完全不同的名字。

另外，果然让我猜中了，你是在 ntfs 分区才出问题的。

难以解决啊。如果 bean 能来解决，那就不一样了。

尽量采用 FAT 格式，万不得已，才使用 ntfs 格式。我们在英文论坛上其实已经发现有关 ntfs 的问题了，都是难以解决的。

emutemp · 发表于 2014-4-27 20:21:23

本帖最后由 emutemp 于 2014-4-27 20:28 编辑

用winhex没找到定位文件位置的功能，用o&o defrag定位的。

文件1，这是grldr可以列表无法读取的

文件2，这是grldr可以读取的

文件1在文件2之前，并且都在120G磁盘的靠前的位置。簇视图中蓝色的格子即文件所占簇的位置。

2个文件其实也就相隔2个簇格子。

		自动登录	找回密码
密码			注册

[讨论] grldr无法识别SSD盘上经碎片整理后的文件？

点评