再次整理C盘空间删除占空间的无用文件
通过删除升级补丁给WinXP的C盘释放一些空间有碰到C盘空间紧张了,再次做整理。
1. 删除了 /LocalSetting 下ApplicationData 目录中VisualAssist下的目录,VisualAssist这个东东用着方便,不想竟然占用好几百兆的磁盘空间(看了一下目录下的文件,好像每次保存一下文件都会在这边保存一个文件的备份,看来无限制的取消操作的代价不小啊)
2. 删除了 /Windows/Insaller 目录下的一些msi, msp 文件
————-
感慨一下微软XP系统的文件搜索功能,感觉就是一个废物,搜索磁盘上大于10M的文件列表,明明符合条件的文件在那儿,可它偏搜不出来。
————-
网上找了一篇文章 WINDOWS目录下的几大无用的地方,讲Windows下哪些目录文件可以放心做删除。
以下这些都是用软件很难或根本无法解决的,通常需手动清理:
1、X:\Windows\Internet Logs
即使只是一般应用,这个目录下的文件在一年以后能有上百M,如果不是2G的话。好在没什么特别的,全部删除就行了,删不掉的话UNLOCKER跟上。(个人经常做,没事的)
2、X:\WINDOWS\Fonts
其中90%的英文字体大多数人一生中不会用一次,保留几种时尚,其它就OVER吧。(养成良好习惯,不用经常光顾)
3、X:\WINDOWS\Installer
这是一个能让人怒火熊熊的地方。
使用 Windows Installer 技术制作的安装程序会在Installer 目录里面添加一个备份的安装文件用于今后的配置、补丁安装等操作。当用户运行一个补丁程序的时候,Windows Installer 将msp文件释放到 Installer 目录以后,开始引导用户进行补丁的安装。如果用户在引导的时候点击了取消操作或补丁安装必备条件不足而导致安装失败的时候,Windows Installer 将退出安装流程,但是会把释放到 Installer 目录里面的msp文件保留下来。如果用户再次运行同一个补丁程序,Windows Installer 又会在 Installer 目录里面生成一个新的msp文件(文件名和上一次的不同),而不会利用上一次释放产生的msp文件。这样一来,第一次产生的msp文件将会永久的存留在磁盘上,成为彻底的无用文件。尤其是安装了Office补丁后,不仅会在Installer文件夹下留下安装程序的备份,还会往Installer\$ PatchCache
当我们装完一些程序后,硬盘容量的占用会数倍于程序尺寸的部份原因就在于此。 “便于日后的安装维护”———这种话就象一个德高望重的SB在主席台上流着口水说出来的,它之所以说错是因为这种“完整”保留安装文件的做法实际上只方便了写程序的人,而根本没把用户放眼里。对于安装过VS2003或2005补丁的人来讲,Windows Installer的这种无赖表现与咱们中国的瑞星倒是有得一拼。
先来说下: 单纯Installer下的文件要复杂得多,不推荐简单删除(除非已肯定不卸载、不升级),可用WICleanup把绝对多余的清理掉。4、JAVA的临时文件
自从SP2已不集成微软的JVM以来,99%的人大概都装了SUN的JRE吧,如果默认安装完毕后就什么都不管的话,JAVA临时文件的默认尺寸是1G(JRE 6)!
这种文件倒不在Windows下,但建议大家:控制面板—JAVA—常规—临时INTERNET设置然后把目录换走,改变尺寸或干脆禁用“保存在我的计算机上”
5、X:\WINDOWS\Driver Cache
WINDOWS自带的驱动程序,可全部删除,自己上网下载和自己有关的最新驱动保存在系统盘之外。以上这几招是任何时候都可用的,不存在系统崩溃(要崩溃了欢迎你杀我全家),很轻松清理1G—5G的空间,用兔子完全没有这种效果。
一度很困惑:作为唯一掌握WINDOWS全部底层技术的微软,应该是最有资格开发系统清理软件的,尽管WINDOWS也确实带有一个这种功能,可那显然只是一个摆姿势臭美一番的东西,为什么会这样?太忙?日理万机?微软这种一往无前不回头看一眼的姿态很是让我感动了几小时,后来恍然大悟:这种系统冗余正是微软需要的!回想一下古时候的WINDOWS 3.1也就是十张软盘吧,可现在的Vista是2G!由此可见一种简单的逻辑:用户的设备压力将加强硬件厂商的销售和研发,从而为微软提供更高级别的硬件平台。没有这种支撑,盖茨明天的早餐吃什么?作为全球软件业的老大,微软只是在很多时候看上去象个SB而已,
Popularity: 24% [?]
Random Posts
stl中vector,list,deque的使用准则
在stl中提供了vector, list,deque几种可当作列表使用的数据结构,他们都是动态增长的,在这三者之中选择的准则主要是关注插入特性以及对元素的后续访问要求。
vector
表示一段连续的内存区域每个元素被顺序存储在这段内存中。对vector 的随机访问效率很高 。但是在任意位置而不是在vector 末尾插人元素则效率很低,因为它需要把待插入元素右边的每个元素都拷贝一遍。类似地删除任意一个而不是vector的最后一个元素效率同样很低,简而言之,删除非末尾元素效率比较低
deque
也表示一段连续的内存区域但是与vector 不同的是它支持高效地在其首部插入和删除元素它通过两级数组结构来实现一级表示实际的容器第二级指向容器的首和尾
list
表示非连续的内存区域并通过一对指向首尾元素的指针双向链接起来从而允许向前和向后两个方向进行遍历在list 的任意位置插入和删除元素的效率都很高指针必须被重新赋值但是不需要用拷贝元素来实现移动,另一方面它对随机访问的支持并不好访问一个元素需要遍历中间的元素另外每个元素还有两个指针的额外空间开销
对这几种容器类型选择的一些准则
如果我们需要随机访问一个容器则vector 要比list 好得多
如果我们已知要存储元素的个数则vector 又是一个比list 好的选择
如果我们需要的不只是在容器两端插入和删除元素则list 显然要比vector 好
除非我们需要在容器首部插入和删除元素否则vector 要比deque 好
这几个标准容器类和数据结构对应关系
vector => 数组、list => 链表、deque => 队列
实际上对于小的对象vector 在实践中比list效率更高
容量是指在容器下一次需要增长自己之前能够被加入到容器中的元素的总数容量只与
连续存储的容器相关例如vector deque 或string。 list 不要求容量capacity()操作
长度size 是指容器当前拥有元素的个数为了获得容器的当前长度我们调用它的size()操作
vector 的动态自我增长越频繁元素插入的开销就越大。一种解决方案是当vector 的开销变得非常大时把vector 转换成list 另一种经常使用的方案是通过指针间接存储复杂的类对象.reserve()操作允许程序员将容器的容量设置成一个显式指定的值,但通常会导致性能退化
Popularity: 41% [?]
Related
使用getpwnam来配合setuid限制运行程序的账号
编写的daemon程序通常是在开机的时候使用root账号开启,这样对系统的安全存在隐患,需要将程序像vsftp等一样,在启动daemon启动后以一个较低权限的账号来运行。
经过查找资料,发现有setuid 和 setgid 两个函数可以使用,不过这两个函数需要传入 数字的编号,不方便程序配置上的设置,再经查资料,发现有getpwnam和getgrnam函数可以用,这两个函数都是传入一个名称返回对应的结构体数据。
-
#include <stdio.h>
-
#include <pwd.h>
-
#include <grp.h>
-
-
int main()
-
{
-
struct passwd * pw;
-
char *username = "nobody";
-
pw = getpwnam(username);
-
if (!pw) {
-
printf("user %s is not exist\n", username);
-
return -1;
-
}
-
setuid(pw->pw_uid);
-
-
char * groupname = "www";
-
struct group * grp = getgrnam(groupname);
-
if (!grp) {
-
printf("group %s is not exist\n", groupname);
-
return -1;
-
}
-
getgid(grp->gr_gid);
-
-
// ….do things……
-
}
passwd结构体的定义如下
-
struct passwd {
-
char * pw_name; /* Username. */
-
char * pw_passwd; /* Password. */
-
__uid_t pw_uid; /* User ID. */
-
__gid_t pw_gid; /* Group ID. */
-
char * pw_gecos; /* Real name. */
-
char * pw_dir; /* Home directory. -*/
-
char * pw_shell; /* Shell program. */
-
};
group结构体的定义如下
-
struct group {
-
char * gr_name; /* Group Name. */
-
__gid_t gr_gid; /* Group ID. */
-
char **gr_mem; /* Pointer to a null-terminated array of character
-
pointers to member names.. */
-
}
Popularity: 25% [?]
Random Posts
php处理xml soap数据的一些小工具
由于要编写MMS彩信服务,搜索了一些php上关于WebService soap处理的相关工具,虽然最后没有使用php直接来处理彩信的收发,但是资料工具整理一下,供以后类似需要的地方使用。
处理Soap数据
- 1. NuSoap
- 2. php5内带的soap模块
- 3.WSO2 WSF/PHP
这个网上的介绍的很多
需要添加相应的扩展,要不然不能使用。
这个看上去不错,不过没有做尝试
处理wsdl 的辅助工具
- 1. WSDL to Php Code
- 2. WSDL2php
- 3. WSDLInterpreter
这个只提供在线的转化,需要将wsdl文件放在外网可以访问的网络上,然后在 http://1018-media.com/wsdlstubgen/ 这个地址生成所需要的代码。不过这个网址要使用代理才能访问。
所在网址: http://www.urdalen.no/wsdl2php/
这个生成的代码最详细,有wsdl中的数据类型定义生成,方便做数据校验处理。
所在网址: http://code.google.com/p/wsdl2php-interpreter/
Popularity: 36% [?]
Related
带附件内容的Soap数据包格式分析
MMS彩信发送在正常的soap xml包体外还需要附加彩信数据,经过抓包分析,发现采用 multipart/related 方式发送。
start部分发送的是Soap的数据包,其他为附加的彩信文件, 采用头部的boundary设定来做多块数据的分隔。
一个抓下来的部分包
post的header头部分
POST /wespa_mms/services/SendMessage HTTP/1.1 Content-Type: multipart/related; boundary=MIMEBoundaryurn_uuid_31E20DB13F6FA8BB9A1234336210043; type="text/xml"; start="<0.urn:uuid:31E20DB13F6FA8BB9A1234336210044@apache.org>” SOAPAction: “” User-Agent: Axis2 Host: 127.0.0.1:5555 Transfer-Encoding: chunked
post的数据体部分
--MIMEBoundaryurn_uuid_31E20DB13F6FA8BB9A1234336210043 Content-Type: text/xml; charset=UTF-8 Content-Transfer-Encoding: 8bit Content-ID: <0.urn:uuid:31E20DB13F6FA8BB9A1234336210044@apache.org> <?xml version=’1.0′ encoding=’UTF-8′?>xml包体内容 –MIMEBoundaryurn_uuid_31E20DB13F6FA8BB9A1234336210043 Content-Type: text/plain Content-Transfer-Encoding: binary Content-ID: <att_file2> file2文件内容 –MIMEBoundaryurn_uuid_31E20DB13F6FA8BB9A1234336210043 Content-Type: text/plain Content-Transfer-Encoding: binary Content-ID: <file_1> file_1文件内容 –MIMEBoundaryurn_uuid_31E20DB13F6FA8BB9A1234336210043–
Popularity: 42% [?]
Related
使用indy解析http协议的multipart上传数据
MMS彩信的数据附在Soap包后面,在正常解析soap的xml文件外,还需要对使用multipart/related编码上传的数据做解析处理,在indy中提供了解码类。
处理解码时,需要TIdMessageDecoderMIME负责实际的解码, TIdMIMEBoundary从头信息中做边界信息查找。
解码函数
-
procedure DecodeFormData(const sHeader: String; ASourceStream:TStream; sSavePath: String);
-
var
-
bEnd : Boolean;
-
sTmp: String;
-
Decoder: TIdMessageDecoderMIME;
-
ds: TStream;
-
begin
-
bEnd := False;
-
Decoder := TIdMessageDecoderMIME.Create(nil);
-
-
try
-
// 设置附件的边界
-
Decoder.MIMEBoundary := TIdMIMEBoundary.FindBoundary(sHeader);
-
Decoder.SourceStream := ASourceStream;
-
Decoder.ReadLn;
-
-
repeat
-
Decoder.ReadHeader; // 读入分块的Header信息
-
case Decoder.PartType of
-
mcptUnknown:
-
raise Exception.Create('Unknown form data detected');
-
mcptText:
-
begin
-
sTmp := Decoder.Headers.Values['Content-Type']; // 获取ContentType
-
ds := TMemoryStream.Create;
-
try
-
Decoder := Decoder.ReadBody(ds,bEnd);
-
// 如果取的数据仍然是由多块组成,则进行递归处理
-
if AnsiSameText(Fetch(Tmp, ';'),'multipart/mixed') then
-
DecodeFormData(sTmp, ds, sSavePath)
-
else
-
// 根据需要使用Dest的数据
-
finally
-
FreeAndNil(ds);
-
end;//try
-
end; // mcptText
-
-
mcptAttachment:
-
begin
-
// 处理附件的文件名
-
sTmp := ExtractFileName(Decoder.FileName);
-
if sTmp <> '' then
-
sTmp := sSavePath + sTmp
-
else
-
sTmp := MakeTempFilename(sSavePath);
-
-
ds := TFileStream.Create(sTmp, fmCreate);
-
try
-
Decoder := Decoder.ReadBody(ds,bEnd);
-
finally
-
FreeAndNil(ds);
-
end;//try
-
end; // mcptAttachment
-
end; // case
-
until (Decoder = nil) or bEnd;
-
finally
-
FreeAndNil(Decoder);
-
end;//try
-
end;
使用OnCreatePostStream 创建用来接受HttpPost数据的Stream
-
CreatePostStream(ASender: TIdPeerThread; var VPostStream: TStream);
-
begin
-
VPostStream := TMemoryStream.Create;
-
end;
最后在OnCommandGet中做解析处理
-
OnCommandGet(ASender: TIdPeerThread; ARequestInfo: TIdHttpRequestInfo; AResponseInfo: TIdHttpResponseInfo);
-
var
-
sContentType : String
-
begin
-
sContentType := ARequestInfo.ContentType;
-
-
if AnsiSameText(Fetch(S, ';'), 'multipart') then begin
-
DecodeFormData(sContentType, ARequestInfo.PostStream, 'c:temp');
-
end else
-
// 根据需要对请求数据做处理…
-
end;
Popularity: 44% [?]
Related
Indy 的 ReadTimeOut 设置失效?
最近在做MMS彩信接口程序,因为不使用Java平台,运营商所提供的Java版的MMS开发包无用,只好按照通信协议用indy直接连接服务端发送拼装好的数据封包来做处理。
为了将自己程序发出的封包和使用java开发包发出的数据包做对比,使用indy做了一个简单的tcpserver来接收发出的封包数据做保存。发现设置的ReadTimeOut设置无效,到了设置的超时时间仍然会处于阻塞状态,只有连接断开才可以继续下去。
网上搜索了一下,发现这个问题是Indy早期版本存在的Bug,indy采用的是阻塞模式,如果Server端未返回信息,这个readln会一直等下去,设置的TimeOut不会起作用(处于死循环中,没有跳出条件),是个BUG。
INDY团队给出的解决办法如下:
第一种:
对ReadFromStack函数的最后一小段做修改:
…
until (LByteCount <> 0) or (Connected = False);
…
修改为:
…
until (LByteCount <> 0) or (Connected = False) or (Result = -1);
…
第二种:
在 ReadFromStack() 的后面 // TimeOut 后面位置
…
// Timeout
if ARaiseExceptionOnTimeout then begin
raise EIdReadTimeout.Create(RSReadTimeout);
end;
Result := -1;
…
修改为:
…
// Timeout
Result := -1; // MOVED!
if ARaiseExceptionOnTimeout then begin
raise EIdReadTimeout.Create(RSReadTimeout);
end else // ADDED!
break; // ADDED!
…
按照以上方法中的一个做了修改,再次接受数据内容,不会处于死等问题。
Popularity: 27% [?]
Related
eclipse出现 “Cound not Create the java virtual machine” 错误解决
下载安装了一个Eclipse 3.2 版的,运行 eclipse.exe 出现 “Cound not Create the java virtual machine” 错误,程序退出。
网上查了资料,也有人碰到这个问题。http://cityhunt.javaeye.com/blog/198186 按照其介绍修改小 -XX:PermSize 的值,结果不起作用,后来尝试将-Xmx和-XX:MaxPermSize都修改小,问题消失
-
-Xmx512m
-
-XX:MaxPermSize=128m
-
-XX:PermSize=64m
造成这个问题的原因估计是 eclipse 启动时要jvm预先分配的内存过多,而系统的内存资源又不够导致的。
Popularity: 24% [?]
