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整理后读取一切正常。

不点 · 发表于 2014-4-27 17:54:45

本帖最后由不点于 2014-4-27 17:55 编辑

可以用 blocklist 命令列出碎块。是的，它只有一个碎块，但你试试看，可否列出它的碎块。

我估计，整理碎块之后，文件被放置在物理位置靠后的连续扇区序列上了，而这可能超出了 bios 的访问能力。

把你的 ssd 格式化，重新拷入文件，那么通常就是连续的了。启动时要用到的那些文件，应该先拷，以便它们能够占据有利的地势，即占据较小的扇区号，从而能够被 bios 访问到。

其实这种问题很普遍，你想想就知道了。大家遇到这类问题，首先就应该想到 bios 的处理能力问题，自己就能解决，避免去询问别人。

emutemp · 发表于 2014-4-27 18:13:43

对该文件使用blocklist命令，依然是“ERROR15,:File not found”。

另外，应该跟文件是否在硬盘前部无关。通过o&o defrag软件对文件所在硬盘块的定位，同样2个连续的2G的文件，硬盘数据簇的位置相隔不远，位置靠后的grldr也可以读取，反而是靠前的出error15。

emutemp · 发表于 2014-4-27 18:56:21

想到一点，有没有可能，对于这个文件，在windows下和grldr下读取到的文件起始位置是不同的？

windows下读取到的是整理后的正确位置，grldr读取到的是整理前的位置，这样导致grldr在那个位置找不到文件？
（这个想法只是瞎猜）

联想到之前大家讨论内存盘时，vsuite软件直接生成的内存盘镜像文件，即使文件是连续的，用grldr读取也会提示文件不连续，一定要拷出到其他分区再拷回，grldr才认可文件连续。（这种现象在机械盘上也出现）

会不会这两种现象是同一原理，即windows下的文件定位方式和grldr的文件定位方式不完全一样？

jianliulin · 发表于 2014-4-27 19:21:06

将你的SSD盘用fbinsttool 弄个ud 再用grldr访问ud里面的文件看看

emutemp · 发表于 2014-4-27 19:35:11

SSD盘是有数据的主硬盘，用来做UD有点不放心啊。

我看这个问题是不是也能简化一下：什么情况下，GRLDR能列表文件，但读取时无论cat，还是blockllist确都找不到文件，报ERROR15，File not found ？

jianliulin · 发表于 2014-4-27 19:46:18

可以先用dg无损弄个空的空间出来，格式化时候不选强行格式不会损坏你硬盘上的数据

不点 · 发表于 2014-4-27 19:49:56

你最好给出证据，证明文件的物理扇区位置不是靠后的。WinHex 等工具都有这个功能，查看文件的扇区序号以及扇区内容。

另外，需要提醒一点的是，grub4dos 里面的 NTFS 驱动，恐怕不敢保证 100% 的可靠。虽然很接近 100%，但可能有极少量的失败情况出现。如果真的让你碰上了，那也不算奇怪事。这原因就在于，ntfs 的结构要比 FAT 复杂得多，因此在编程技术上也就更容易出错。

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个簇格子。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ntfs是否设置了压缩？'

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

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

未压缩。

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

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

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

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 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 觉得它们属于异常情况，不予支持。

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

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

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

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

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-2 07:09:46

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

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

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

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个匹配数据。

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

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

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

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

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-3 10:25:55

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

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

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

这样截是否正确？

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

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

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

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

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

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

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

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

点评

点评

点评

点评

点评