tr1(Technology Report 1)目录是允许直接包含的


之前c++新标准讨论过程中，下一代c++标准还没有完成,但一部分内容已经形成一定共识，这部分库被单独放在tr1目录下。但是最终纳入下一代c++标准的结果与tr1时有所不同，unordered_map就变成两个了(你可以diff一下两个实现) 。如果你按照tr1的标准来使用unordered_map，就应该包含tr1/unordered_map。如果不考虑这个兼容性，那就应该使用最终的unordered_map



bits目录不应该直接包含
gcc的具体实现都放在了bits目录里面（也就是具体实现细节，和boost库的detail目录一样，都是库的编写者的内部实现，库的使用者不应该直接包含这些目录里面的文件）你包含的头文件会间接包含bits里面的文件

@lovefree13
dnscrypt
fedora https://copr.fedoraproject.org/coprs/codeblock/dnscrypt-proxy/
ubuntu https://launchpad.net/~shnatsel/+archive/ubuntu/dnscrypt
archlinux community自带
你用哪个发行版？

楼主老实交代，是不是玩galgame怕被人发现

感觉传统意义上的操作系统在用户隐私这方面的短板越来越明显了...都在一个账户下，任意运行的程序都有当前账户全部文件的读写权限。要么像linux一样，只使用可信的软件，要么像ios/android或者docker一样，应用彼此也是隔离。

理论上哈...假如分区已经加密完毕，那么使用中断电不会导致数据丢失，但断电时正在写入的文件（或者正在被改写的文件）将可能错误。

影响数据是否能被正常解密的关键是truecrypt的加密头。一旦你的分区加密完成，且你没有更改密码，这个加密头是不会变更的，也不需要更改或写入。因此已经被加密的数据也不会因为意外断电而无法解密。但假如truecrypt正在改写加密头时（比如你更改密码）断电，有可能导致加密头的写入错误从而导致已有数据无法解密


不过也不用太担心，根据truecrypt的spec，加密头带有自校验，且在被加密分区的尾部有一个备份。假如出现上述情况，truecrypt发现第一个加密头校验失败，是可以从备份加密头恢复的。当然这些都是理论上...

以上说明是在加密已经完成的情况下的情况下。使用truecrypt加密分区（从不加密到加密）还要有一个加密过程，在加密过程中如果断电会发生什么情况不知道...可以去看源码。有些加密软件(比如veracrypt)是可以在加密过程中主动暂停并正常关机重启再继续的，应该是对加密进度有记录。


加密有可能导致性能下降，但新的cpu如果支持aes-ni指令集，aes加密（最常见的磁盘加密算法）是非常快的，带来的影响微乎其微（当然也要加密软件支持aes ni指令集）

由于加密是按块进行，所以加密内容因为断电而导致内容损失的效果上会严重一点，可能至少会丢失一个加密块（取决于加密算法）

难道你们代码不提交到版本管理系统？

...少写了一个011

如果不要求顺序的话
这不就是把 000到 111 所有二进制数字列一遍吗...

000
001
010
100
101
110
111

所有情况就是 2^n次方

@msg7086 这种解释方式应该也是有兼容性问题了。不过根据楼主提供的这个扫描图片，倒是有点可能，假设diskgenius对mbr是按照512字节来解释的，那么扫描到的第一个分区大小465G，按照8倍，大概是3720G，很接近楼主说的3.7TB。只不过楼主恐怕不能用diskgenius来恢复（因为他没有按照4K来解释扇区），
保险的话楼主仍然需要硬盘对拷和linux挂载，但是不需要自己去找ntfs的起始扇区了，只要看diskgenius扫出来的第一个ntfs分区的位置，即是正确位置(字节位置，不是扇区)，另外楼主遇到的读错误，也可能也是diskgenius没有正确按照4k解释扇区的缘故（应该是从某一点之后一直出现读错误，且不能读的扇区都是连续的）

@msg7086 嗯，有人遇到MBR用在5TB的情况下http://www.chiphell.com/thread-1280806-1-1.html，看来我的理解是有问题的。不过我还是很好奇，这样的硬盘在linux下或者一些分区工具下能正常识别吗?

@msg7086 容量小8倍确实可以说明不同情况下对LBA的解释不一样了，那容量变小时你还能正常访问分区吗？按说起始扇区位置也变了，应该不能访问才对

@msg7086 嗯，还有一段
Both the partition length and partition start address are sector values stored in the partition table entries as 32-bit quantities.


The sector size used to be considered fixed at 512 (29) bytes,


and a broad range of important components including chipsets, boot sectors, operating systems, database engines, partitioning tools, backup and file system utilities and other software

had this value hard-coded.


Since the end of 2009, disk drives using a new technology known as Advanced Format and employing 4,096-byte sectors (4Kn) have been available, although the size of the sector for some of these drives was still reported as 512 bytes to the host system through conversion in the hard drive firmware and referred to as 512 emulation drives (512e).

总之没有实际的4k硬盘mbr分区超过2TB的实例的话，我觉得还是没有说服力的。要不新开个帖子看看是否有其他人有这样的实例吧

@msg7086 按照我的理解，即使是4K扇区的硬盘，在MBR解释之下，也应该按照模拟512字节一个LBA来寻址。wiki中有这样一段描述
MBR partition entries and the MBR boot code used in commercial operating systems, however, are limited to 32 bits. Therefore, the maximum disk size supported on disks using 512-byte sectors (whether real or emulated) by the MBR partitioning scheme (without using non-standard methods) is limited to 2 TB.

@msg7086 按照我的理解，按照mbr来解析时，不论物理扇区是否4k，lba都按照512字节解释。当然也可能不对。我没这个条件，如果有实例的话贴一个第一扇区看看吧。

@sketch33 如果出现读扇区错误建议楼主立刻停止扫描并断电，现在出现读错误且扫描没有结果的情况，读写有可能加剧更多不可恢复错误。应该准备一个同大小硬盘，用二进制对拷后，在拷贝盘上进行恢复操作，原盘尽量不操作

@msg7086
Since block addresses and sizes are stored in the partition table of an MBR using 32 bits, the maximum size as well as the highest start address of a partition using drives that have 512-byte sectors (actual or emulated) cannot exceed 2 TB−512 bytes (2,199,023,255,040 bytes or 4,294,967,295 (232−1) sectors × 512 (29) bytes per sector). Alleviating this capacity limitation was one of the prime motivations for the development of the GPT. 我不知道MBR怎么寻址超过2TB.除非LBA按照4k扇区解释。MBR远早于4k，我很怀疑这样做的兼容性。当然如果你有实例可以贴出来研究研究。

@msg7086 应该不是MBR。MBR分区不能超过2TB，但楼主分成了一个大分区，且用量超过2tb

提供一个思路哈，可在只读情况下确认数据是否仍然存在。

4T硬盘分成一个大分区，那么应该是GPT分区表，文件系统为NTFS。

1.快速确认丢失分区是否正常

假定当时你用win7自带的磁盘管理对硬盘分区，且第一个分区就是你的大分区，
那么第一个分区的起始字节应该是1024 KB 处
(https://msdn.microsoft.com/en-us/library/windows/desktop/hh848035(v=vs.85).aspx)

那么winhex或者dskprobe跳转到1024KB处，
开头应该会有NTFS字样，
512字节前应该会有 disk read error occurred BOOTMGR is missing BOOTMGR is compressed Press Ctrl+Alt+Del to restart字样
512字节处十六进制会有55AA

找到这个标记，可以确认仅仅是分区表被破坏，分区数据问题不大。

如果用dskprobe打开这个扇区，可以选择功能 view as ntfs partition table（大致是这个字样吧）
将会把这个扇区按照ntfs扇区头来解释，将显示分区大小等信息，如果和你原来的分区一致，那么
可以确认没有问题了


2.假如上述流程不可行，那么可以尝试寻找GPT分区表备份
按照http://en.wikipedia.org/wiki/GUID_Partition_Table的说明
硬盘最后一个扇区应该是GPT分区表的备份，楼主可尝试使用winhex或者dskprobe读取最后一个扇区（4T硬盘应该是4k扇区。按照wiki的说法，应该是最后一个4k扇区，当然也可能是512字节，都尝试一下），看看有没有GPT分区表的标识
"EFI PART"
如果找到，那么可以按照wiki的说明，看一看你的分区表描述是否反应了之前你记住的大概分区结构
（也就是你说的一个超大分区。不过GPT分区的磁盘也可能在头部多一个小分区，可以忽略）。再跳转到
这个超大分区的起始扇区，按照1的流程来确认是否找到的就是丢失的分区

3.GPT分区表备份找不到或者与你原来的分区结构不相符（某些分区工具不会可能不会更新备份的GPT分区表，将导致这个问题），那只有raw搜索了 。在winhex里面搜55AA的hex （可选cond %512 = 510意即只搜512扇区结尾），直到找到NTFS的分区起始处。 NTFS分区的起始扇区在NTFS分区的结尾也有一个备份（与分区头的一样），因为你分成了一个整个的大分区，所以也可以在硬盘的结尾处搜索。找到这个扇区后使用dskprobe的view as ntfs partition table打开之后，用jump to partition start ，即可跳转到ntfs分区的起始扇区。


4.已经确认分区起始位置后如何操作？
切换到linux系统，使用losetup 配合你找到的分区起始扇区的*字节位置*
将sdx (插入硬盘后的序号) 挂载为loop device(比如/dev/loop0)，然后用mount -t ntfs-3g /dev/loop0 /mnt/xxx -o ro (只读挂载) （这一段就是大概，具体命令楼主完成前面的步骤之后再详细确认）

如果没有问题的话，原来的分区已经可以在/mnt/xxx下可以直接访问了。这个流程不需要写入磁盘，也不用恢复分区表 。可以说是无损恢复。如果为了保险，就把文件全部拷贝出来，格式化了再写入（是否考虑换个硬盘？）。要是敢于折腾，可以linux 下gdisk写入一个新的gpt分区表，再手动把分区的起始结束扇区写入，如果正确，硬盘直接恢复成可读状态。

也有过过相同的想法...不过后来一测试，也就是百度盘上传能满速。最终选择的是encfs+百度盘，文件名和内容加密都是加密的，在本地可以直接挂载读写。只要用百度客户端同步下加密存储的目录即可，推荐楼主试试。windows版用的是encfsmp(同时支持mac)，linux版encfs 可用fuse，这样也解决了跨平台的问题。不过没有楼主需要的冗余功能。