无忧启动论坛

标题: grldr无法识别SSD盘上经碎片整理后的文件？ [打印本页]

作者: emutemp 时间: 2014-4-27 16:47
标题: grldr无法识别SSD盘上经碎片整理后的文件？
本帖最后由 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
本帖最后由不点于 2014-4-27 17:55 编辑

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

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

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

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

作者: emutemp 时间: 2014-4-27 18:13
对该文件使用blocklist命令，依然是“ERROR15,:File not found”。

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

作者: emutemp 时间: 2014-4-27 18:56
想到一点，有没有可能，对于这个文件，在windows下和grldr下读取到的文件起始位置是不同的？

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

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

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

作者: jianliulin 时间: 2014-4-27 19:21
将你的SSD盘用fbinsttool 弄个ud 再用grldr访问ud里面的文件看看

作者: emutemp 时间: 2014-4-27 19:35
SSD盘是有数据的主硬盘，用来做UD有点不放心啊。

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

作者: jianliulin 时间: 2014-4-27 19:46
可以先用dg无损弄个空的空间出来，格式化时候不选强行格式不会损坏你硬盘上的数据

作者: 不点 时间: 2014-4-27 19:49
你最好给出证据，证明文件的物理扇区位置不是靠后的。WinHex 等工具都有这个功能，查看文件的扇区序号以及扇区内容。

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

作者: emutemp 时间: 2014-4-27 20:21
本帖最后由 emutemp 于 2014-4-27 20:28 编辑

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

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

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

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

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

作者: 不点 时间: 2014-4-27 21:03
我注意到两个文件名的第一个字母的大小写不一样。也许是这个细节造成的？

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

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

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

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

作者: emutemp 时间: 2014-4-27 21:07
文件名大小写试过了，无论都改成大写还是都改成小写，都一样的效果。

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

作者: emutemp 时间: 2014-4-27 22:02
只是解决倒是有办法，只要把文件拷到其它分区再拷回来就可以了。

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

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

作者: jack95 时间: 2014-4-27 23:17
ntfs是否设置了压缩？'

作者: emutemp 时间: 2014-4-27 23:47
本帖最后由 emutemp 于 2014-4-27 23:49 编辑

未压缩。

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

作者: 不点 时间: 2014-4-28 05:43
你自己可以设置 debug on 或 debug 0xFFFFFFFF 打开调试输出，看看会出现什么错误。甚至你也可以修改源代码，增加输出信息，确定出错的地方。

作者: emutemp 时间: 2014-4-28 16:33
本帖最后由 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
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
我感觉是 wcontig 产生的问题。没有按规范删除原文件目录，致使 G4D 首先找到并使用该目录。但由于 Don't support >4K ，所以拒绝执行。
也许是 G4D 或略了文件删除标记，没有继续寻找下一文件目录？可能性不大。

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

作者: emutemp 时间: 2014-5-2 02:10
本帖最后由 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
本帖最后由 2011yaya2007777 于 2014-5-2 07:21 编辑

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

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

作者: emutemp 时间: 2014-5-2 15:45

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

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

Hex_search.rar

383.38 KB, 下载次数: 6, 下载积分: 无忧币 -2

按Vram2k32g

作者: mfkwgij 时间: 2014-5-2 17:43
有图放上来看以西阿里！~

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

作者: emutemp 时间: 2014-5-2 22:55
本帖最后由 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行。

HEX_INDX_FILE.rar

76.49 KB, 下载次数: 3, 下载积分: 无忧币 -2

INDX_FILE0

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

作者: emutemp 时间: 2014-5-5 16:21
该分区每簇8个扇区，winhex有相对偏移定位功能，用相对偏移定位：
（0x89cdf×8+0）×0x200=0x89CDF000（该分区的相对偏移位置）
（0x59295a×8+0）×0x200=0x59295A000（该分区的相对偏移位置）

这样截是否正确？

DataADD.rar

210.59 KB, 下载次数: 13, 下载积分: 无忧币 -2

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

作者: emutemp 时间: 2014-5-5 17:31

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

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

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

作者: 2011yaya2007777 时间: 2014-5-5 18:54
那就算了。辛苦了。

作者: 2011yaya2007777 时间: 2014-5-6 10:13
本帖最后由 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 是是在什么环境下，使用什么工具复制进来的？

作者: emutemp 时间: 2014-5-6 14:32
本帖最后由 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处的截图。

Hex_End_FILE0.rar

349.52 KB, 下载次数: 11, 下载积分: 无忧币 -2

Hex_End_FILE0

作者: 2011yaya2007777 时间: 2014-5-20 17:06

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

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

grldr.rar

141.21 KB, 下载次数: 4, 下载积分: 无忧币 -2

作者: emutemp 时间: 2014-5-23 15:43
幸苦2011yaya2007777了。
现在在外地出差，没有原环境，可能要等到回去才能测试了。

作者: emutemp 时间: 2014-9-6 17:57
终于有条件测试了。

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

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

作者: huaqingyuan 时间: 2015-1-6 21:43
SSD不同于机械硬盘，不建议做整理！

欢迎光临无忧启动论坛 (http://wuyou.net/)