|     网站首页    |   

WinSxS文件夹怎么瘦身

作者:admin

发布时间:2020-02-04

浏览次数:

  winsxs的文件夹位于Windows根目录,是一个超大的文件仓库,系统所在分区几乎所有的系统文件都在那里至少有一个备份。有兴趣的网友不妨通过搜索功能在winsxs搜一下公用视频、公用图片、公用音乐文件夹里的文件,你会发现那些精简系统时已经被删除了的文件在winsxs里还可以找到影子。假如系统文件被删除或者破坏,用命令sfc /scannow就可以恢复,但如果将winsxs里面的任何一个重要的组件删除,sfc命令就会失效。系统在线更新的过程是旧版本文件被新版本的取代,旧文件自动备份在winsxs里;卸载补丁的过程是系统新版本文件被旧版本的取代,而旧版本文件的来源正是winsxs。XP也有类似的功能,但XP下备份文件是可以直接删除的,Vista和Win7下不行。所以Vista和Win7占用的空间随着更新增多会越来越大,而且大得惊人。winsxs里的文件非常重要,建议不要删除,以我长期的实践经验,暂时发现只有ManifestCache和Temp两个文件夹里的缓存文件才可以安全删除。

  特别提醒:网上所有精简winsxs的方法都有一定的危险性(微软官方的工具除外),例如“删除Backup文件夹或用空文件取代同名文件”,虽然它叫Backup,但里面绝对不是备份文件而是关系到系统能否正常更新和正常“打开或关闭Windows功能”的重要文件,某些大量被转载的文章都在误导人。某软件提供删除Windows内置字体,帮助文件的方法,其实这对于精简系统是没有任何意义的,字体和帮助文件在winsxs还有一个备份,两个相同的文件共用一个储存空间,换句话说,删除前和删除后C盘可用空间不变!但是注意,如果你查看文件或者文件夹的属性,他们都会占空间。又如有人提出删除winsxs里同名文件较低版本的一个或几个,这是一个很好的想法,但问题是有些同名文件的不同版本都有重要作用,都不能删除,例如Framework的相关组件。

  因为磁盘空间不够了,所以想起来清理一下系统垃圾文件,主要目标就是臭名昭著的winsxs目录。这个winsxs就是微软为了解决“dll hell”问题,结果是好比在windows系统里安置了一个毫无节制不断增大的“肿瘤”。听说微软研究院现在在研究这个问题,不过我想我的硬盘空间不够大,等不到这个补丁出来的时候,所以只好自己动手了。

  winsxs目录下的文件都是系统要用的各种库文件,system32下存放了这些dll的最新的版本,所有老版本的dll都放在winsxs下。所以只要你安装程序或者更新补丁,system32下的文件就会被更新,而同时winsxs就会增加一些旧文件,所以我们的C盘空间就在持续不断地减少,直到磁盘容量不够,被迫重装系统为止,如果你足够幸运,可以直接安装最新的SP的话,或许可以为winsxs节约一点微薄的空间。

  这里的各个部分用下划线分割,其中我们关注的是“6.0.6000.16386”部分,它表示旧文件的版本号,之前则是唯一文件标识,之后是语言,最后部分是散列值(防止名字冲突)。

  本工具的设计思想就是删除所有的旧文件。所有满足如下全部条件的目录都会被移动到C:/Windows/winsxs_del目录中。

  工具源代码如下:请保存为winsxs_clear.bat即可。所有不再需要的文件会移动到c:/windows/winsxs_del目录中,可以直接进行删除。

  rem 检查参数是否匹配 %winver%, 先跳过前两个.同时准备组合新版本匹配名称,nv1存当前版本,nv2存当前的前一个版本

  rem 至此则为 ver_prefix 开头 且 不等于 winver 的目录名,检查最新版本是否存在,存在则可删除旧的

  代码导读有助于大家理解程序和算法,但是基本的批处理语法就不讲了,有几年编程经验的我想也看得懂。以下是大致几个要注意的地方:

  代码的开头部分是用ver命令获取系统的版本号,并且存放到%winver%变量中,比如我的ver命令返回就是“Microsoft Windows [版本 6.0.6002]”,为了获取这个“6.0.6002”,所以要做一些处理,另外,%ver_prefix%中存放的是类似“6.0.600”,为了比较旧版本号用途。

  因为批处理无法实现嵌套嵌入功能,比如我想把从目录中分解出来的6.0.6000.16386和%ver_prefix%进行比较,就无法实现了,只好用代码生成来处理,在18~24行就是生成代码,该代码在63行和69行调用。26行负责把控制转移到新生成的文件中执行。

  因为winsxs目录是有特殊权限的,所以先用takeown命令设置当前用户为拥有者,然后用cacls修改目录权限,最后用move指令将目录转移到winsxs_del目录中。如果出现程序无法运行的情况,请手工移动回去即可。

  从客户的角度,最常见的版本问题就是我们所说的 DLL Hell 问题。简单地讲, DLL Hell 是指当多个应用程序试图共享一个公用组件(如某个动态连接库(DLL)或某个组件对象模型(COM)类)时所引发的一系列问题。最典型的情况是,某个应用程序将要安装一个新版本的共享组件,而该组件与机器上的现有版本不向后兼容。虽然刚安装的应用程序运行正常,但原来依赖前一版本共享组件的应用程序也许已无法再工作。在某些情况下,问题的起因更加难以预料。比如,当用户浏览某些 Web 站点时会同时下载某个 Microsoft ActiveX? 控件。如果下载该控件,它将替换机器上原有的任何版本的控件。如果机器上的某个应用程序恰好使用该控件,则很可能也会停止工作。

  在许多情况下,用户需要很长时间才会发现应用程序已停止工作。结果往往很难记起是何时的机器变化影响到了该应用程序。用户可能会回忆起一周前安装了一些东西,但安装与目前看到的状态并没有任何明显的关联。 更糟的是,现在很少有诊断工具帮助用户(或帮助他们的技术支持人员)确定有什么问题。

  这些问题的原因是应用程序不同组件的版本信息没有由系统记录或加强。而且,系统为某个应用程序所做的改变会影响机器上的所有应用程序—现在建立完全从变化中隔离出来的应用程序并不容易。

  很难建立一个隔离应用程序的一个原因是当前运行时环境只允许单独版本组件或应用程序的安装。这个限制意味着组件的编写者必须以向后兼容的方式编写他们的代码,否则当他们安装新组件的时候会有终止已有应用程序的风险。实际上,如果可能的话,编写永远向后兼容的代码是非常难的。在 .NET 中,side by side 概念是版本问题的核心。Side by side 是在同一台机器上同时运行不同版本的相同组件的能力。使用支持并列的组件,编程人员不必努力维护严格的向后兼容,因为不同的应用程序自由使用某个共享组件的不同版本。

  现在安装应用程序是多步过程。一般,安装一个应用程序包括复制许多软件组件到磁盘,和在系统中进行一系列描述那些组件的注册项。

  注册表中的项和磁盘上文件的分隔使复制应用程序和卸载他们非常困难。而且,在注册表中完全描述某个 COM 类所需的许多项之间关系非常松散。这些项常常包括联合类、接口、类型库和 DCOM app ID 的项,不涉及任何放在注册表文档扩展或组件类别的项。要时常手工保持这些项的同步。

  最后,需要该注册足迹激活任何 COM 类。这极大地复杂了发布分布式应用程序的过程,因为必须到每个客户端的机器进行适当的注册项。

  如今另一个共同问题是:对一个正在运行的应用程序进行更新是不现实的。这是 Web 应用程序最大的问题,Web 应用程序必须停止工作然后重启动以更新应用程序使用的 COM 类。

  这些问题主要由从组件自己分离传来的组件描述引起的。换句话说,应用程序不是自描述的和独立的。