系统【原创】WIN7系统下替换字体失败的罪魁祸首——硬连接技术 - 第2页

lockfan · 2009-09-10, 15:50

市场是不会相信色厉内荏的占有率说明一切问题.
不支持的东西应该明确告诉用户而不是因为说这个东西不好说自己的更为先进.

另回楼上...这么干不是为了说明任何问题只想说按照楼主的思路的确可以解决WIN7的字体替换 =.=

我是先直接替换掉了winsxs的文件然后删除fonts下的字体再直接mklink新的字体文件到fonts下的.

今天又试验了下不做mklink 直接在winsxs的相关文件夹下点字体安装但是重启后字体文件依旧是丢失的, mklink这一步似乎必不可少

直接同时复制字体文件到fonts和winsxs下的确是可以成功替换的. 但是在winsxs下点字体右键安装却不行..

**随风飘扬** · 2009-09-10, 20:41

引用:

作者: lockfan

市场是不会相信色厉内荏的占有率说明一切问题.
不支持的东西应该明确告诉用户而不是因为说这个东西不好说自己的更为先进.

另回楼上...这么干不是为了说明任何问题只想说按照楼主的思路的确可以解决WIN7的字体替换 =.=

我是先直接替换掉了winsxs的文件然后删除fonts下的字体再直接mklink新的字体文件到fonts下的.

今天又试验了下不做mklink 直接在winsxs的相关文件夹下点字体安装但是重启后字体文件依旧是丢失的, mklink这一步似乎必不可少

直接同时复制字体文件到fonts和winsxs下的确是可以成功替换的. 但是在winsxs下点字体右键安装却不行..

非也.楼主和你都陷入硬链接的误区了.

首先说明一点,硬链接是NTFS文件系统的特性,并不是Win7才有的新特性
其次,它是从系统底层支持的文件连接.

至于字体替换,其实根本不需要mklink，而为什么有些少数人直接替换成功了，那只是因为操作环境不同造成的巧合。

有兴趣的同学可以做这个测试：

1.全新安装一个Windows7.
2.以管理员身份启动CMD，结束掉任何有前台界面的进程（包括资源管理器、任务管理器）
3.CMD切换到Fonts目录，执行takeown和icalcs命令取得控制权，ren命令将simsun.ttc重命名为simsun.ttc.bak（此处，虽然是硬链接的文件，但是由于是系统底层实现的，所以在上层看来其实就是真实的文件，这点楼主有误解，不会存在“硬连接文件”和“字体文件”不同无法识别的问题）。
4.复制你新的字体文件到Fonts目录。注意：WinSXS中有的Simsun.ttc副本可以不管。如果你不开心直接干掉也可以，不过此时无法删除，因为已经被系统加载了。可以在以后删除。
5.关键一步：删除系统字体缓存文件
6.重启，你会发现替换成功完成，并没有发生什么字体丢失问题。

大部分人失败是由于没有上面的第五步，而并不是没有删除WinSXS或没有用mklink的后果。
有兴趣的同学可以自行测试一下。

lovespring · 2009-09-17, 16:00

说的太复杂了，其实和楼主描述有出入。
--------------------------------------------------------------------------
那有些人就要问了，如果我把Fonts文件夹中的文件和WinSXS文件夹中的文件同时替换了呢？还是不行的，正如前文所说，Fonts文件夹中的文件本身只是硬连接文件，是虚假的文件，是用硬连接命令mklink造出来的文件，你却用真实的文件来替换，这是不对的。而把WinSXS文件夹中的原始文件替换，但是没有用mklink重新创造硬连接信息，也是没有任何效果的。
--------------------------------------------------------------------------
硬链接的各方，不管替换那一个，其修改都会反映到其他文件上面去，至少我好几次替换系统文件的经验是这样的。
比如，替换破解的主题的3个dll，在Ubuntu（双系统，Ubuntu不会理会Win7的权限的）下直接复制到这3个文件到System32中，为了验证winsxs是否也同时修改了，特意查询了其中同名文件的Hash值，结果两边一致，正面winsxs中已被修改。
也就说，如果替换的是链接的文件，就会把其链接源文件替换掉。因此，字体替换后不起作用，大概就不是文件硬链接的问题了，可能和楼上说的原因一样。
另外，先删除目标文件，再复制替换文件，这样的操作没有试过，估计，就和上面不一样了。楼下的可以试试。

vencky · 2009-09-23, 20:13

引用:

作者: 随风飘扬

非也.楼主和你都陷入硬链接的误区了.

首先说明一点,硬链接是NTFS文件系统的特性,并不是Win7才有的新特性
其次,它是从系统底层支持的文件连接.

至于字体替换,其实根本不需要mklink，而为什么有些少数人直接替换成功了，那只是因为操作环境不同造成的巧合。

有兴趣的同学可以做这个测试：

1.全新安装一个Windows7.
2.以管理员身份启动CMD，结束掉任何有前台界面的进程（包括资源管理器、任务管理器）
3.CMD切换到Fonts目录，执行takeown和icalcs命令取得控制权，ren命令将simsun.ttc重命名为simsun.ttc.bak（此处，虽然是硬链接的文件，但是由于是系统底层实现的，所以在上层看来其实就是真实的文件，这点楼主有误解，不会存在“硬连接文件”和“字体文件”不同无法识别的问题）。
4.复制你新的字体文件到Fonts目录。注意：WinSXS中有的Simsun.ttc副本可以不管。如果你不开心直接干掉也可以，不过此时无法删除，因为已经被系统加载了。可以在以后删除。
5.关键一步：删除系统字体缓存文件
6.重启，你会发现替换成功完成，并没有发生什么字体丢失问题。

大部分人失败是由于没有上面的第五步，而并不是没有删除WinSXS或没有用mklink的后果。
有兴趣的同学可以自行测试一下。

首先说明我对文件系统一窍不通，我只是从解决问题的角度去想要怎么设计。
磁盘上的物理文件是data，系统对文件的描述是metadata。
我的理解是硬链接就是metadata的变化，metadata中对data的描述信息增加或者减少了。
但是无论哪个描述信息都能用来访问data。假如metadata中所有的描述信息都删除了，那么data就会被删除。（data会被删除是我从网上看来的。在我看来metadata被删除以后系统已经无法知道data了，所以系统无需物理删除data，只是认为data那块物理地址是“干净”的，可擦写的，从安全角度来说需要物理删除，可能这个策略就会产生不同的文件系统设计了吧）。
首先修改文件。你打开文件，就是使用了metadata中某条信息访问了data，自然修改对所有的硬链接是同步的，因为data只有一份。
其次是删除。关键问题是data到底有没有删除。不管是我上面说的哪种策略，总结起来就是到底还能不能访问data。假如data删除，那么自然就不能访问了。
现在考虑上面的这个问题。（sorry，对win的命令从来没读过，只知道linux的，有错望指正）从字句上看，winsxs重命名的那个操作，仅仅是改变了metadata，而大家争论的那个硬链接，自然还是能访问对应的data的。假如不能访问，那么可以认为win的硬链接设计有父子关系（或叫主从关系吧），或者重命名操作会改变data（这个不 make sense）。之后的复制呢？那是一个新的data，除非系统把原来那个字体的metadata中的某条描述信息复制给了这个data的metadata，不然原来的描述信息(metadata)怎么能够访问后来的data？假如能够访问，我认为是系统本身可能设计了一个处理逻辑，如果2个不同的metadata中描述信息重合，那么这2个metadata认为描述的是同一个data，系统自然给处理成一个metadata，也就是说这2个metadata可以访问同一个data。

---------- 帖子于 20:13 更新 ---------- 之前内容发布于 20:05 ----------

引用:

作者: vencky

首先说明我对文件系统一窍不通，我只是从解决问题的角度去想要怎么设计。
磁盘上的物理文件是data，系统对文件的描述是metadata。
我的理解是硬链接就是metadata的变化，metadata中对data的描述信息增加或者减少了。
但是无论哪个描述信息都能用来访问data。假如metadata中所有的描述信息都删除了，那么data就会被删除。（data会被删除是我从网上看来的。在我看来metadata被删除以后系统已经无法知道data了，所以系统无需物理删除data，只是认为data那块物理地址是“干净”的，可擦写的，从安全角度来说需要物理删除，可能这个策略就会产生不同的文件系统设计了吧）。
首先修改文件。你打开文件，就是使用了metadata中某条信息访问了data，自然修改对所有的硬链接是同步的，因为data只有一份。
其次是删除。关键问题是data到底有没有删除。不管是我上面说的哪种策略，总结起来就是到底还能不能访问data。假如data删除，那么自然就不能访问了。
现在考虑上面的这个问题。（sorry，对win的命令从来没读过，只知道linux的，有错望指正）从字句上看，winsxs重命名的那个操作，仅仅是改变了metadata，而大家争论的那个硬链接，自然还是能访问对应的data的。假如不能访问，那么可以认为win的硬链接设计有父子关系（或叫主从关系吧），或者重命名操作会改变data（这个不 make sense）。之后的复制呢？那是一个新的data，除非系统把原来那个字体的metadata中的某条描述信息复制给了这个data的metadata，不然原来的描述信息(metadata)怎么能够访问后来的data？假如能够访问，我认为是系统本身可能设计了一个处理逻辑，如果2个不同的metadata中描述信息重合，那么这2个metadata认为描述的是同一个data，系统自然给处理成一个metadata，也就是说这2个metadata可以访问同一个data。

打完了回头看看发现个问题，metadata应该是文件系统对物理文件的描述，而非系统的描述。如果是系统的话那问题就大了去了。

**Toni** · 2009-09-24, 07:13

讨论方向很好的
这样的主题多多益善
让小盆友们都学学
但是不要打起来
和气点

cctrv · 2009-10-03, 03:19

引用:

作者: 随风飘扬

非也.楼主和你都陷入硬链接的误区了.

首先说明一点,硬链接是NTFS文件系统的特性,并不是Win7才有的新特性
其次,它是从系统底层支持的文件连接.

至于字体替换,其实根本不需要mklink，而为什么有些少数人直接替换成功了，那只是因为操作环境不同造成的巧合。

有兴趣的同学可以做这个测试：

1.全新安装一个Windows7.
2.以管理员身份启动CMD，结束掉任何有前台界面的进程（包括资源管理器、任务管理器）
3.CMD切换到Fonts目录，执行takeown和icalcs命令取得控制权，ren命令将simsun.ttc重命名为simsun.ttc.bak（此处，虽然是硬链接的文件，但是由于是系统底层实现的，所以在上层看来其实就是真实的文件，这点楼主有误解，不会存在“硬连接文件”和“字体文件”不同无法识别的问题）。
4.复制你新的字体文件到Fonts目录。注意：WinSXS中有的Simsun.ttc副本可以不管。如果你不开心直接干掉也可以，不过此时无法删除，因为已经被系统加载了。可以在以后删除。
5.关键一步：删除系统字体缓存文件
6.重启，你会发现替换成功完成，并没有发生什么字体丢失问题。

大部分人失败是由于没有上面的第五步，而并不是没有删除WinSXS或没有用mklink的后果。
有兴趣的同学可以自行测试一下。

我认为这个答案是正确的。
字体这个东西，的确没有应用到“NTFS LINK”。
另外，那个不叫硬链接。