需要增加UD中放置单个大小4G以上的文件的支持吗

sunsea

在时空论坛里：http://bbs.znpc.net/forum.php?mo ... tid=6733&page=1
看到这个帖子后
上面写个发起调查
我就先在这里发吧
这里人气旺
这是不点原话：

请看 asm.S 中如下变量的定义，红色标明的几个变量，采用了两个 long 整数的宽度，已经是 64 位的量了。

        . = EXT_C(main) + 0x90

VARIABLE(filesize)
        .long   0, 0
VARIABLE(saved_mem_upper)       /* maximum contiguous memory in KB starting at 1M and below 4G */
        .long   0
VARIABLE(saved_partition)
        .long   0

        . = EXT_C(main) + 0xA0

VARIABLE(saved_drive)
        .long   0
VARIABLE(no_decompression)
        .long   0
VARIABLE(part_start)
        .long   0, 0

        . = EXT_C(main) + 0xB0

VARIABLE(part_length)
        .long   0, 0


        . = EXT_C(main) + 0x120

VARIABLE(filemax)
        .long   0, 0

VARIABLE(filepos)
        .long   0, 0

  

你所说的限制，应该是 ud 文件系统的设计，不支持超过 4G 的文件。这与 FAT 文件系统不支持超过 4G 大小的文件是一样的。

使用任何软件，都有前提条件的，它都有限制的。不要超越它的限制而去使用它。

试想：你能让 FAT32 支持 4G 以上的文件长度吗？肯定不能，因为一旦 FAT32 被改造、增强为支持超过 4G 文件长度以后，它就不再叫做 FAT32 了，而成为一个全新的文件系统了。

这是它的结构定义。当初没有保留修改的余地。这是放在磁盘上的数据的结构，不是随便想改就能改的。修改了就等于制造了一个新的文件系统，不再是 UD 了，或者可以叫做 UD64。

如果改成 64 位的，会造成不兼容，与以前的各种工具都不兼容。

当然，也可以舍弃兼容性而强行修改。但这里就有一个代价问题：值不值得？这是焦点。

在 UD 区究竟有多大的必要去放置一个很大的映像文件？放在别的一个 NTFS 分区可否成为一个替代方案？

有多少人需要在 ud 区存放超过 4G 的大文件？人数少 = 意义不大。

没有不可能的事情，只有权衡。

bean 当初设计它，也就没打算支持超过 4G 的文件。

UD 的目的主要是启动，不是为了存放大文件。bean 的设计是正确的。

少数人需要存放大文件的，也一定可以用别的方法变通实现，而不一定真的需要放在 ud 区中。

如果有必要，将来可以发起一个投票，看看有多少人要求 ud 一定要支持超过 4G 的文件。

根据投票的结果，再来决定是否创造新的 UD64 格式。

就先顺着这个意思发起吧

[ 本帖最后由 2011czmxbb52 于 2012-10-8 20:20 编辑 ]

不点

标题没讲清楚，容易让人误解。

有可能误解为放置的所有文件的总容量超过 4G。这是错误的。应该是单个文件的长度超过 4G。

roytam1

UD區也不能比4GB大，data_start是uint32

xianglang

U盘才4Gb的路过……

sunsea

原帖由 不点 于 2012-10-8 17:06 发表
标题没讲清楚，容易让人误解。

有可能误解为放置的所有文件的总容量超过 4G。这是错误的。应该是单个文件的长度超过 4G。

谢谢指点
已经修改

freesoft00

个人感觉没有必要。。。

jianliulin

UD區也不能比4GB大，data_start是uint32

目前ud可以大于4G，最大为2T

[ 本帖最后由 jianliulin 于 2012-10-9 10:03 编辑 ]

不点

这个问题我个人可能腾不出时间来编写代码。但我可以帮助 chenall、Roy、Bean 以及其他可能的开发者们进行前期的分析准备。

目前我有两点认识：

1、这个问题根本上是修改 fbinst 格式化工具，让它产生新一代的 ud 分区（姑且称为 UD64）。从根本而言，这不是 grub4dos 的事，而是 fbinst 的事。当 UD64 诞生以后，grub4dos 需要修改代码来适应这个新的文件系统。新的文件系统有可能在一个时期内带来大量的不兼容，不兼容于以前用来操作 ud 的工具软件，包括某些 PE 中的 32 位保护模式下的 UD 工具，可能都得修改，否则可能无法支持新的文件系统。就是说，UD64 会带来不兼容。

因此，在没有足够理由的情况下，在 “ 出力不讨好 ” 的情况下，尽量应该避免去做这个工作。这是我的第一层意见。

2、技术上增强 UD 让它支持超过 4G 的大文件是可以实现的，除了前面提到的“ 肯定要产生不兼容性 ” 问题以外。

就是说，技术上不存在困难（除了 “ 肯定会带来不兼容性 ” 以外）。这是我的第二层意见。

2010lzu

除非特别必要，还是暂时不加的好。毕竟现在真正有这个需求的人不多。大大们有这个时间可以做些更值得做的事情。

zxw

没有必要……………………

del111

大于4G的文件就应该放到NTFS,exFAT可见区里面去，UD64这个文件系统很没有必要的。

M

我都可以，反正大大们出哪个版本我就用哪个版本。

xiaoy

倘若G4D能将UD MAP成一个硬盘分区出来  那这个4G支持是很有必要的

应用举例  在硬盘上划分UD空间    启动时G4D来引导系统，需要时，G4D能将UD空间MAP为一个硬盘分区，来做一键还原非常理想 还可以在里面让一些单文件系统 如VHD  WIM等。非常安全  有点HPA的感觉了。

试了一下map (ud)+1 (hd) 不成功
map (ud) (hd)是把U盘可见分区MAP成了另一个硬盘

jianliulin

pecmd已经可以直接把ud中的一个文件map成一个分区，很有必要支持大于4g的文件

俊采星驰

我觉得应该向前看，如果造成不兼容，那么能用老的UD系统解决问题，不升级好了。新的文件系统主要适应新的功能。至于用哪一个版本，这是应用者自己选择的事情。

pseudo

有干劲就干！

mdyblog

xiaoy 发表于 2012-11-3 08:41
倘若G4D能将UD MAP成一个硬盘分区出来  那这个4G支持是很有必要的

应用举例  在硬盘上划分UD空间    启 ...

MBROSTOOL
已经实现了  UD扩展区  MAP成一个硬盘分区出来。
PECMD也实现了。
grldr也实现了。(包内有)， 如果用默认的 grldr, 需要调用包内的 ldudpe来map UD。
还可以锁住UD区，防止fbt  fbi  等破坏。
现在 可以直接启动PE， 并在PE中加载 UD到盘符(Z:)，访问外置。

效果：
6269#


PECMD.EXE （88.05.52）  UDM+FIXDRV.WCS 也支持 UDEXt

PE启动时， 自动加载  UDEXt效果图：

sunsea

mdyblog 发表于 2015-2-21 18:13
MBROSTOOL
已经实现了  UD扩展区  MAP成一个硬盘分区出来。
PECMD也实现了。

是正常bean老大写的那个ud吧

826773297

不需要，不需要！！！！！

mdyblog

sunsea 发表于 2015-2-22 10:31
是正常bean老大写的那个ud吧

是滴。

yjd

mdyblog 发表于 2015-2-21 18:13
MBROSTOOL
已经实现了  UD扩展区  MAP成一个硬盘分区出来。
PECMD也实现了。

是个好消息。

这几天在考虑弄隐藏。。之前一直是ud和一个可见区fat32+畸形目录，中毒到不会。
ud主分区放grub4dos。可见区一堆启动文件，pe，和efi。上次文件分配表出错损坏了好多文件，修补半天-_-!!，09年到现在出现过2次。就是有时候在别人电脑有可能导致这样。

好多隐藏方案如u+啥的，都比较不适合我的文件，我是h3的pe，大多数是文件解开方案。还有efi，bootmgr启动。一丢隐藏区启动就麻烦了。。

看你介绍看来可以把这些东西丢ud的扩展区里，有空详细看看您的文章。

2012GDFSHE

要是能突破单文件4g,我个人是支持的，虽然现在用vhd系统，不过对个别机还是很需要,最大好处就觉能放gho文件进ud中，比隐藏安全很多，也不会误删等多种好处

2012GDFSHE

要是能突破单文件4g,我个人是支持的，虽然现在用vhd系统，不过对个别机还是很需要,最大好处就觉能放gho文件进ud中，比隐藏安全很多，也不会误删等多种好处

zyphio

fbinst产生的初衷有：
1.解决不现BIOS下U盘第一扇区位置不同的问题！
2.更好的载入grldr！
而主数据区和扩展数据区是在后来加入的“附加功能”！所以，从fbinst产生的初衷来看，增加单文件4GB的支持没多价值！存GHO文件？！

yyz2191958

不需要