grub4dos 外部命令 wenv [2010-10-17 ]

zhaohj

再次测试，只要在FAT分区上读过文件，NTFS上就没问题了。

chenall

文件太小？NTFS不支持这么小的文件。

记得好像目前的NTFS代码访问小于4KB的文件经常会出问题的说。

zhaohj

是的，大于4KB没有问题。这是否也是BUG？

xianglang

我在上网本和笔记本上，使用我的那个压缩3KB的背景图，会花屏，但是如果不压缩的话，却很正常——我的分区也是NTFS格式的。由此看来，可能与GZIP压缩有关啊。G4D的版本，从今年开始的都是一样，之前的版本没试过。

zhaohj

不是压缩问题，是文件太小的原因。如果不压缩小于4KB也一样（不过不压缩至少背景图片肯定超过4KB）。

chenall

以前很早就会有这样的问题了吧，具体要问一下bean。

记得NTFS分区上小于4KB的文件用GRUB4DOS访问偶尔是会出问题的。

sgw888

我在虚拟机测试的时候,CAT 是可以正常显示内容的. 第一次可以正常读出啊.
之前测试的时候,总也读不出. 读多少次也是0. 虚拟机,DISKGEN3创建的NTFS. 然后,DOS下NTFS4DOS,拷贝的文件,从真实机拷到虚拟机.  这儿有几个问题,一,NTFS是DISKGEN创建的,第二,DOS下拷贝的,使用了NTFS4DOS,而且是从真实机又转到虚拟机的.  使用的是 8.3短文件名.

后来,在PE下,格式化了一下NTFS的盘,从真实机重新拷贝了一下文件. 格式化之前,打开原来拷贝的文件也没发现什么问题,可以正常解压缩的.
再试的时候,就正常了.

hhh333

原帖由 chenall 于 2010-5-10 17:33 发表
以前很早就会有这样的问题了吧，具体要问一下bean。

记得NTFS分区上小于4KB的文件用GRUB4DOS访问偶尔是会出问题的。

就我测试的情况来看，应该较早或者是从一开始就有这个问题，可能要仔细看NTFS读写的代码才能找出来。应该算一个隐藏得较深的BUG吧。　

[ 本帖最后由 hhh333 于 2010-5-10 17:52 编辑 ]

hhh333

在没找到错误所在时，我只能将图稍微做大一点了，不过这总是个安全隐患。

不点

hhh333 因为做出了重大发现，而被授予国家重大诺贝尔科学发现金质奖章。

chenall 你得把这个 bug 解决了。实在解决不了，再求助于 bean。

这次难度系数，向上翻腾8周半，向下翻腾5周半，转体960度。

－－－－－－－－－－－－－－－

根据大家的研究，初步感觉，问题与 gz 无关。那么可能是 ntfs 下小文件访问时容易出现的问题。

因此就要注意， NTFS 支持模块代码中，究竟什么地方与此有关？读小文件的过程，与读大文件的过程有何区别？

只要找到差别，就缩小了范围，再加上一些调试代码，也就比较容易找到问题的根源了。

sgw888

我又在家里的机器做了一下测试。这次使用的GRUB4DOS版本是0.4.4 2009-3-31. 通过XP的BOOT.INI进行引导GRLDR。

我从论坛下载附件，直接保存到了我的电脑的D盘，为了测试，我使用WINRAR解压开，并重新使用7-ZIP进行了压缩。  这样，要测试的文件一共有三个，一个是直接下载的，一个是解开的，一个是重新压缩的。
直接下载的是： (hd0,4)/BACK[1].XPM.GZ ,解开的是 (hd0,4)/BACK[1].XPM/BACK.XPM ,重新压缩的是 (hd0,4)/BACK.XPM.gz .

我使用下面的命令进行了测试。

cat --hex --length=150 (hd0,4)/BACK[1].XPM.GZ
cat --hex --length=150 (hd0,4)/BACK.XPM.gz
cat --hex --length=150 (hd0,4)/BACK[1].XPM/BACK.XPM

压缩的GZ文件都无法读取，都是0，而解包的XPM可以读取。
以上命令重复执行多次，结果一样。

我的机子有两块硬盘，第一块全是NTFS的分区 (hd0) ，第二块硬盘第一个分区是FAT32的。

接下来，我读取了一下FAT32的分区，使用上面的CAT命令随便找了一个文本文件显示了一下。 再执行上面的命令，结果还是一样。无法读取GZ文件。 这说明应该是GRUB4DOS对NTFS上面比较小的文件读取有BUG。

上面的测试至少说明，压缩文件本身并没有问题，换用不同的压缩软件，读取的时候，结果一样。 换用7-ZIP压缩后文件大小不一样，比原来小。
更换了GRLDR的版本有同样的问题。0.4.4版本也有这个问题.

chenall

我抽空试了一下，结论同上。

但是，感觉好像读取错误导致进入了死循环。

另外还有一点开启fstest后可以正常使用。

先运行
fstest提示
Filesystem tracing is now on
然后就可以访问了，晚上有空再具体跟踪一下看看。

xianglang

我补充说明一下我的背景图花屏的问题：同样是存放在NTFS分区里的D:\GRUB里压缩后3KB大小的背景图，在我的分辨率为1024*576的上网本、分辨率为1280*800的海尔本本上，就肯定会花屏；但是换到我的第一代P4老古董里，用的是1280*1024分辨率的LCD，正可以正常显示。据此我猜测，压缩后背景图花屏或者不能显示的原因，可能与显示器的分辨率、显示模式、显卡芯片等等显示部分有关。

[ 本帖最后由 xianglang 于 2010-5-11 12:14 编辑 ]

zhaohj

现在的问题是不管什么格式，小于4KB的文件在NTFS上读不出来。
先运行fstest固然读出来了。看来离解决不远了。

[ 本帖最后由 zhaohj 于 2010-5-11 12:31 编辑 ]

sgw888

期待尽快解决. 又要辛苦CHENALL了.
昨天从 zhaohj 那里学到东西了,加深了对 write 命令的认识. 搞清了 内存地址与(md)设备之间的联系与区别.

另: 借这个地方问个问题. 总是短消息问别人,回复了大家也看不到.

map /menu (rd) 与 map --mem /menu (rd) 有区别吗??   (rd)本来就是内存驱动器吧??
还是我理解有误?  或者应该这样理解:  map /menu (rd) 仅仅是做了映射,我们在访问 (rd)的时候,指向了 /menu,这里假设 / 指的是硬盘,我们在读取 (rd)的时候,实际上是记问的硬盘??  而 map --mem /menu (rd) 是把 /menu 放到内存以后,又映射到了 (rd) ,然后,我们访问 (rd) 的时候,是访问的内存?

另外,使用上面的命令,是不是要求 文件是 UTF-8格式的???  还是其它要求?

zhaohj

map对文件的要求是这个文件是连续存放的，要求比较高。
如果连续存放的文件也可用map。

这个与UTF-8格式无关，任何文件都可以。如SRS.ZIP也可以。

不点

map /menu (rd) 与 map --mem /menu (rd) 有区别吗??

正如你猜测的那样，没区别。你后来的说法是错的。

(rd) 就在内存了。map /menu (rd) 就是把 /menu 拷贝到内存，并让 (rd) 指向那段内存区域（的开头）。

至于说 menu 的内容采用什么编码，则与 (rd) 和 map 都无关了，menu 只是一个文件罢了。

hhh333

我觉得不是读所有的＜4K的都不行，如menu.lst文件做得比较小时也照样可以读出。我推测可能是以二进制方式读文件时出问题。现在还不肯定是读文件错还是解压缩错。我再测试一下。

＝＝＝＝＝
刚才用cat命令读了一下/boot/grub下的echo(148B)和goto(224B)好象没问题

[ 本帖最后由 hhh333 于 2010-5-11 21:19 编辑 ]

zhaohj

原帖由 hhh333 于 2010-5-11 20:46 发表
我觉得不是读所有的＜4K的都不行，如menu.lst文件做得比较小时也照样可以读出。我推测可能是以二进制方式读文件时出问题。现在还不肯定是读文件错还是解压缩错。我再测试一下。

＝＝＝＝＝
刚才用cat命令读 ...

今天再测试了一下，RAR、ZIP、sys、EXE的<4KB都没有问题，只有GZ的有问题

看来还是GZ压缩的问题。

目前暂时用fstest on来解决！

hhh333

那就基本肯定是GZ解压模块的问题；或者splashimage命令代码存在瑕疵。

sgw888

原帖由 hhh333 于 2010-5-12 13:17 发表
那就基本肯定是GZ解压模块的问题；或者splashimage命令代码存在瑕疵。

应该不是 splashimage 命令的问题,因为 cat 命令也不正常,我在测试的时候也是花屏的,花的很厉害.

chenall

问题应该是出在ntfs模块上（可能有一个隐藏的BUG）

对NTFS模块只有上次有稍微了解了一下，还不是很清楚，抽空继续研究下，看看能不能找出来。

sgw888

原帖由 <i>zhaohj</i> 于 2010-5-11 18:40 发表 <a href="http://bbs.wuyou.net/redirect.php?goto=findpost&pid=1949643&ptid=159851" target="_blank"><img src="http://bbs.wuyou.net/images/common/back.gif" border="0" onload="if(this.width>screen.width*0.7) {this.resized=true; this.width=screen.width*0.7; this.alt='Click here to open new window\nCTRL+Mouse wheel to zoom in/out';}" onmouseover="if(this.width>screen.width*0.7) {this.resized=true; this.width=screen.width*0.7; this.style.cursor='hand'; this.alt='Click here to open new window\nCTRL+Mouse wheel to zoom in/out';}" onclick="if(!this.resized) {return true;} else {window.open(this.src);}" onmousewheel="return imgzoom(this);" alt="" /></a><br />
map对文件的要求是这个文件是连续存放的，要求比较高。<br />
如果连续存放的文件也可用map。<br />
<br />
这个与UTF-8格式无关，任何文件都可以。如SRS.ZIP也可以。

<br />

既然是与格式无关.那应该与文件大小有关系.  (rd)是内存驱动器,所以不存在要求文件是连续存放这个问题.请看我的虚拟机截图.
文件不是连续存放的,也可以MAP到 (RD). 但是一个小文件却不可以.

sgw888

上传不了文件.晕.

以下是测试结果
grub>map /fd0.lst (rd)

Error 13: Invalid or unsupported executable format

grub>blocklist /grub/unifont
(hd0,0)68160+8,68208+1

grub>map /grub/unifont (rd)
Autodetect numbers-of-heads failed. Use default value 2
Autodetect sectors-per-track failed. Use default value 18

关于 map 文件到 (rd) ,出错的原因终于找到了.  不是文件格式的原因,也与文件是否连续存放无关,因为(rd)本来就是内存驱动器.
只要文件小于512字节,就会出错. 大于等于512字节的时候是正常的. 因为zhaohj维护的 SRS F6中使用了map  MENU到rd,所以,这是一个需要注意的问题.

另外,我在虚拟机的测试:   关于读取小文件出错的问题:  只有在读取扩展分区NTFS的文件时才报错.  只要读一下主分区NTFS或者FAT分区同名的文件(测试的时候用的是相同的文件),再去读一下扩展分区的文件,就能读取了.另外,读取TXT格式的时候是正常的,100多个字节的TXT文件也是正常的,应该还是跟GZ文件有关系.

[ 本帖最后由 sgw888 于 2010-5-12 17:45 编辑 ]

willsion

grub4dos功能越来越强了。不过，个人认为，应该在“启动”这方面下大工夫，现最新版本，还没有圆满解决启动acronis等一些特殊格式的img、iso问题，也许是我了解太浅。说错的话，请各位不要抛砖头。

chenall

我还是没能找到真正的原因。

由于使用fstest以后可以使用，所以就查了一下相关的代码，修改了一行和这个有关的代码，目前看起来使用正常，就是不知会不会有后遗证。

http://grub4dos-chenall.googleco ... 2010-05-13-test.zip

有条件的多多测试一下。

基于nufans.net不点上传的2010-05-13版

zxw

@chenall:
请教g4d_off这个外置命令是什么意思？

不点

g4d_off 是个外置的 halt 命令，用来关机的。这是 zw2312914 写的。

如果 grub4dos 内建的 halt 失败了，可以试试 g4d_off 命令。我倒是觉得应该把 g4d_off 改名为 HALT。

zxw

谢谢不点指点，我也感觉是个外置 halt 命令，但疑惑没有命名为 halt 而不能确定。

另5.13的chenall修改版本似乎没有hidenmenu命令，难道也外置了？

[ 本帖最后由 zxw 于 2010-5-13 17:34 编辑 ]

hhh333

外置需要规划，不能想起什么就写一段小程序作外置，提供一个执行外置的接口是对的，但不能依赖于外置，外置泛滥不一定是好事。现在执行脚本越来越不好看懂了，这对普及是不利的。应尽量用内置命令，如果觉得确实需要某个很重要的功能则考虑扩展内置命令。到时候不会弄成DOS命令都有相应外置吧？

要么做个外置集合DLL，挂上后就可用外置命令，不然外置程序也越来越多，越来越乱。