大家都知道在数字计算机领域内指的文件在磁盘上的存储是依赖于文件的命名的。
而关于文件的命名在Windows平台和Linux平台式不一样的。比如说，Linux系统对文件名称的大小写字母敏感，而Windows不敏感。详情请查阅“Windows操作系统文件命名规范”和“Linux操作系统文件命名规范”。
昨天我偶然的机会处理了一个在RHEL6.1操作系统上的EXT4分区中的文件夹，这个文件夹盛放的是一个标准用户的Home目录（家目录）。在执行备份过程中，我错误的将其备份（复制）到一个NTFS分区的磁盘中，然后用Windows Server 2008 R2操作系统打开了这个分区。但是我马上认识到了错误，既然已经造成了这个错误就趁机看看Windows是如何处理这个目录的。
下面是此目录(此目录假设以home命名)在EXT4文件系统中的部门文件结构。
/home
根目录中有两个文件夹
/home/workspace
/home/Workspace
两个文件夹中的文件不相同
分别为
/home/workspace/documentcatalog/computing
/home/workspace/documentcatalog/cloudcomputing
和
/home/Workspace/cprograming_desigan/chroot.c
/home/Workspace/cprograming_desigan/a.out
结果当将这个磁盘连接到Windows系统时，首先系统没有报错，可以正常访问磁盘。
接下来我有意识的打开根目录，发现了这个目录中的确有两个文件夹/home/workspace和/home/Workspace，但是当我要访问这两个文件夹时，奇妙的现象就出现了。
结果令我感到很震惊，两个目录中的文件完全相同。所谓的完全就是时间、权限和属性都是完全一样的。
那么没有出现的那些文件哪里去了呢？我还能够正常访问它们吗？
结果肯定是不能。
然后我尝试了复制这个目录（home），发现复制成功，但是不能粘贴，粘贴是有效的，但是实际上执行粘贴命令后没有任何反应。
怎么办？
首先我考虑到了Windows平台中的使用工具CHKDSK，
我在CMD中执行了chkdsk /f G:(假设磁盘分区分配的符号为G:)。
果然在意料之中出现了各种扫描到的错误，都是关于文件索引的错误（可惜我当时忘记了截图）。
当修复完成后，发现可以正常的使用该磁盘分区了。
但是后来遇到的结果依然令我惊讶！原来，CHKDSK这一工具将有以上错误的目录和文件全部都“清除了”！我发现不任何原先有类似错误的文件的位置。
这肯定是我不希望看到的。
当时我很惊恐，因为所备份的磁盘的备份在另一台远程计算机的磁盘上，且处于保护（没有实现共享，即其他主机不可见）状态，而里面又有我当天需要使用的文件。
怎么办？
我想切换到RHEL环境中再试一试，但想了想这个方案不可行，因为Windows已经修复并保存了磁盘的文件系统。
尝试文件恢复？使用文件恢复工具？这个在Windows Server平台上又没有支持较好的软件，这也是一大缺憾。应该是兼容性吧！测试了几次，效果依然不太好。
此刻我又想到了，每次运行CHKDSK这一工具后都会在其分区中产生FOUND.000文件夹，我查看了一下此文件夹中的文件和目录，正好有我要寻找的目录和文件。只是存在错误的目录或文件名称全都变了。总之还好，在RHEL上能正常识别出来。
这次的事故让我体会到了平时关于在文件的命名和备份分区的选择上的注意事项。当当前计算环境中有多个不同的操作系统或者分区类型时就应该本着通吃通用的原则，以保证文件的可用性。