有什么地方比“上海豪享来”还“享来”的，那就是乌鲁木齐“特享来”了。
想来，享来
猫·友·好
跑步归来在小区里慢走，不意间一只花猫凑到脚边，不惊不怯，我迈一步它走两步，忽左忽右，追逗着我的脚步。
我不敢将脚抬高，生怕不小心踩到它。或许花猫亦有所觉察，似有不离不弃之念，一直伴在我左右，边走边叫，喵喵声中却有凄凉之意、抑或欣悦、激动之情，唤起了我无限怜悯。就如女人的眼泪，花猫的喵喵声，同样是人间杀器。
正想着是不是在楼前找找爱猫者所留的猫粮，或者喂它根火腿肠的当口，又一只白猫从草丛中窜出，跃入对面草地里。 一直陪着我的花猫，却是迎头追赶，等我想知道它们去向的时候，两只猫咪早已没了踪影。
呵！有个朋友，真好！
9-18
有朋友今天下午去了仙霞路，归来曰：武警成群结队，有组织有纪律；人群三三两两，看热闹着多，真游行者少，计四五十之众。然，为国、为民者，英雄！
宪法之赋予吾等诸权利，不应因事急而通变，又因势利而喝阻，一而再，再而三，三则亡。
人生来是自由的，却无往而不在枷锁之中 -- 卢梭。
文件系统开发之特殊文件links篇(上)
链接(links)是文件系统最常用的一类特殊文件，一般分为两类：
- 硬链接(hardlink): 硬链接和普通文件(或目录)实际并没有差别，只是它和另外的文件共用一个文件数据体，反过来说就是，同一个文件体可以有多个名字，而且这些名字可以在卷内的任意目录中。类似于同一座房子，却有着不同的门牌号。 硬链接必须在同一卷上，就像门牌号必须附着于房子实体上一样。 Linux文件系统Ext3允许针对目录和文件的硬链接的创建，但Windows文件系统NTFS只允许硬链接的创建于文件之上。造成此差别的原因在于文件系统的实现上的不同，Linux Ext3文件系统对dentry(文件名)和inode(文件数据)的管理是分开的，但对NTFS却不是，Fcb是dentry和inode的合体，二者分不开，这部分以后再详述。
- 软链接(softlink)，同时又有符号链接(symbolic link, symlink)之称。符号链接不同于硬链接，它是一类特殊文件，就像是“邮政信箱”，它只是个指向一个门牌号的别名而已，门牌号可以代表一座房子的实体，但“邮政信箱”并不能。 软链接是可以跨卷的，即软链接自身位置和其目标位置，差个108000里也没关系。 Windows NTFS对符号链接的支持是从Vista才开始的，就是说XP系统并不支持。
对于Windows系统，还有另外两种比较特殊的“链接”：
- Junction: Junction其实是一种符号链接，只是在Win2k或XP系统上符号链接并没有实现的情况下的一个临时替代品。Junction只支持目录链接，不支持文件。Junction是可以跨卷的，因为它本质上符号链接。
- Reparse Point：Reparse Point最早的作为Mount Point（卷加载点）来引入的，但其功能却相当强大，比如上面提到的Symlink/Junction的实现其实都是基本Reparse Point的，再者NTFS的高级特性如Hierarchical Storage，也是通过Reparse Point来实现的。 对Linux Ext3来说，任意子目录都可以是Mount Point。对Windows文件系统NTFS来说，虽然任意子目录也可以作Mount Point，但一旦成为Mount Point，其子目录便转换为了Reparse Point属性，也正是这个实现上的差别导致了Windows系统在链接的操作上出现了不少怪现象。
后面会进一步针对Linux Ext3及Windows NTFS内部对链接的实现进行介绍和分析。
Windows的快捷方式(Shortcut)并不在此文的讨论之列，因为它是Shell层(即Windows Explorer)的行为，并非文件系统本身的特性。
蓝屏，谁之过？
Bug总能在你意想不到的地方给你个措手不及，只是它所带来并不是惊喜，而是Blue Screen Of Death !
既如此，只能兵来将挡。
先介绍一下程序的大体流程：
NTSTATUS
XXXProcessDirents(…)
{
do {
KeEnterCriticalRegion();
ExAcquireResourceSharedLite(&fcb->Resource, TRUE);
/* access several members of fcb structure */
ExReleaseResourceLite(&fcb->Resource);
KeLeaveCriticalRegion();
XXXXProcessDirent(…);
} while (list_is_not_empty(….));
return status;
}
NTSTATUS
XXXXProcessDirent(…)
{
HANDLE handle = NULL;
XXXX_FILE_HEADE fileHead;
……
/* open file */
status = ZwCreateFile(&handle, GENERIC_READ, &oa, &iosb, NULL, 0,
FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE,
FILE_OPEN, 0, NULL, 0);
/* read file header*/
status = ZwReadFile(handle, ioevent, NULL, NULL, &iosb, (PVOID)&fileHead,
sizeof(XXXX_FILE_HEADE), &offset, NULL);
/* check whether file is interesting to us */
if (status == STATUS_SUCCESS && iosb.Information == sizeof(……)) {
/* it’s my taste, haha */
}
/* close file, not interested in it any more */
if (handle){
ZwClose(handle);
}
return status;
}过程比较简单，XXXProcessDirents()会循环调用XXXProcessDirent()，直至列表中所有项全检查完毕。
下面再来看windbg分析吧：
1: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
IRQL_NOT_LESS_OR_EQUAL (a)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high. This is usually
caused by drivers using improper addresses.
If a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: 0abc9867, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000001, bitfield :
bit 0 : value 0 = read operation, 1 = write operation
bit 3 : value 0 = not an execute operation, 1 = execute operation (only on chips which support this level of status)
Arg4: 806e7a2a, address which referenced memory
Debugging Details:
------------------
WRITE_ADDRESS: 0abc9867
CURRENT_IRQL: 2
FAULTING_IP:
hal!KeAcquireInStackQueuedSpinLock+3a
806e7a2a 8902 mov dword ptr [edx],eax
DEFAULT_BUCKET_ID: DRIVER_FAULT
BUGCHECK_STR: 0xA
PROCESS_NAME: System
TRAP_FRAME: b9019bbc -- (.trap 0xffffffffb9019bbc)
ErrCode = 00000002
eax=b9019c40 ebx=00000000 ecx=c0000211 edx=0abc9867 esi=c0000128 edi=8842d268
eip=806e7a2a esp=b9019c30 ebp=b9019c68 iopl=0 nv up ei ng nz na pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010286
hal!KeAcquireInStackQueuedSpinLock+0x3a:
806e7a2a 8902 mov dword ptr [edx],eax ds:0023:0abc9867=????????
Resetting default scope
LAST_CONTROL_TRANSFER: from 806e7a2a to 80544768
STACK_TEXT:
b9019bbc 806e7a2a badb0d00 0abc9867 804f4e77 nt!KiTrap0E+0x238
b9019c68 806e7ef2 00000000 00000000 b9019c80 hal!KeAcquireInStackQueuedSpinLock+0x3a
b9019c68 b9019d24 00000000 00000000 b9019c80 hal!HalpApcInterrupt+0xc6
WARNING: Frame IP not in any known module. Following frames may be wrong.
b9019cf0 80535873 00000000 8896fb20 00000000 0xb9019d24
b9019d10 b79d87ff ba668a30 8859b7e8 00000440 nt!ExReleaseResourceLite+0x8d
b9019d2c b79d8a5c 8a3ff2f0 00000003 ba6685f0 XXXXX!XXXProcessDirents+0xef
b9019d88 b79e163a e2f6b170 00000001 00000001 XXXXX!XXXKernelQueryDirectory+0x20c
b9019ddc 8054616e b79e1530 88a8ae00 00000000 nt!PspSystemThreadStartup+0x34
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16问题出在系统函数ExReleaseResourceLite()及KeAcquireInStackQueuedSpinLock()上，且程序要写的地址为0abc9867 ，明显不对，所以此处可做栈损坏推断。
第一嫌疑要考虑的是，XXXProcessDirents()中有锁保护的部分，此部分是果真是最容易造成栈损坏buffer复制操作。但经过仔细检查及测试，便排除了此部分出错的可能。
在排除第一嫌疑后，就没有明显目标了。只好再接着看windbg log：
貌似KeAcquireInStackQueuedSpinLock()要写的地址是LockHandle的LockQueue->Next，而LockHandle一般都在从当前堆栈分配的，由此可肯定之前对于栈损坏的推断。可问题是，是谁导致的栈损坏。
Stack中有hal!HalpApcInterrupt()调用记录，它是处理APC的软中断。hal!HalpApcInterrupt()会一般会调用nt!KiDeliverApc()来处理线程的APC队列。但当ExReleaseResourceLite()调用的时候，线程还处于临界区内（Critical Section），此时User mode APC及Kernel mode normal APC都会被禁止的，但Kernel mode special APC不会。
Kernel Special APC最常见的情况便是由IoCompleteRequest()添加的：在APC Level中调用IopCompleteRequest()以处理Irp的Stage 2的清理工作。
至此，问题终于有些眉目了。分析代码中唯一有可能导致APC添加的地方就在函数XXXXProcessDirent()中的ZwReadFile()调用，而且fileHead正是于堆栈中分配的。
想到此处，此bug的根据原因便付出水面：
XXXXProcessDirent()没有处理ZwReadFile()返回STATUS_PENDING的情况，此情形下，XXXXProcessDirent()退出并继续执行，而之前的ZwReadFile()的IRP完成操作也在同时进行（还没有完成），并且此完成操作所要写的fileHead地址，正是早已被回收并加以重用的当前栈。
搞清楚之后，便在调用ZwReadFile()后，特别针对STATUS_PENING的情况来调用ZwWaitForSingleObject()以确保读操作全部完成后，再进行下一步操作。
到此，问题解决！
一个蓝屏的问题，竟然如此之绕，不禁让我想起刘震云的《一句顶一万句》，只是这能顶一万句的一句到底是哪句呢？
<下一步打算写写APC相关的东西，操作系统将APC隐藏得太深，总让人捉摸不定！>
钓鱼岛是我们的
上面并不是我的原创，却同样表达了我的意思。印象中是在苏花公路上骑行时，看到一骑机车环岛的台湾哥们，在机车后面特意挂了一个牌子，上面就是这样写的，可惜我怎么也找不到当时拍的照片了。他骑得虽是机车，但因着拍照的关系，我们轮流着一前一后共同骑了很长一段路，中间也曾短暂交谈。虽萍水相逢，却都有着中国心。
今天在google.com.hk上试着搜索钓鱼岛，竟然提示“敏感字”。什么玩意嘛，这个是倒底是哪门子的敏感？！
记得8月中在承德避暑山庄游玩时，同样有个牌子，上面写的是晚清政府，可所有人看了均相视而笑：
真的，还是假的，马上就见分晓了，我且拭目以待。
