我的 USB 记忆棒有一点问题。我可以在 Linux 计算机 (Fedora 20) 上查看和操作 USB 记忆棒上的文件和文件夹，但在 Windows 计算机上使用 USB 记忆棒时，其中一些文件和文件夹不会出现。此外，根据 Windows，USB 记忆棒上存储了近 2.9 GB 的文件，但我可以使用的文件总计只有 500+ MB。我不知道为什么会发生这种情况，但这不是第一次了。我该怎么做才能永久解决这个问题？
答案1
更新
所以，我真的没想到NTFS今天早上我会进行研究，但是，主要感谢下面@AndrewMedico 的评论，我学到了一些东西。
事实是文件streams很奇怪，它们让我感到困惑，但显然它变得更深了。其行为方式非常类似于NTFSfile streams，Transactional NTFS将文件更改提交到某个备用缓存，直到保证更改为止。如果是这样，文件将被原子地、完整地整体提交。我混淆了文件的概念stream- 我仍然相信它一定是一个非常基本相似的概念，并且可能以某种方式涉及，因为每个文件可以有多个named且只有一个unnamed streams- 与明显发生的情况TNTFS.我猜我不是唯一一个:
由于开发人员在应用程序开发过程中需要考虑其复杂性和各种细微差别，Microsoft 正在考虑在未来版本的 Windows 中弃用 TxF API。因此，Microsoft 强烈建议开发人员研究使用替代方案，而不是采用
Transactional NTFSAPI 平台可能在未来版本的 Windows 中不可用。
当我整理下面提到的 Windows 映像时，我遇到了文件消失、重新出现的问题 - 似乎甚至在完全删除磁盘之后 - 这实际上主要是截断它。我当时的理论是——现在仍然是——Linux 缓存没有提交对文件的更改streams。我现在认为它只是没有按照预期的方式处理原子提交：
删除文件
DeleteFileTransacted通过调用该函数删除的文件或目录仍然可见致所有外部读者。*笔记 全部* 处理
handles到文件的事务必须在transaction.如果handles没有正确关闭，则delete不会发生这种情况。在执行删除操作之前，必须关闭文件的所有打开句柄，commit才能将删除操作视为事务的一部分。这是因为，作为 Windows 文件 I/O 子系统的一部分，即使操作未进行事务处理，系统也不会真正删除文件，直到文件的最后一个句柄关闭为止。
删除目录
RemoveDirectoryTransacted通过调用该函数删除的目录仍然可见致所有外部读者。
目录锁定问题
如果在事务中修改文件，则该文件路径的所有目录组成部分都称为固定反对重命名直至交易结束。也就是说，系统防止你从重命名直到事务被提交或回滚。尝试重命名作为在正在进行的事务中已修改的文件的祖先的目录将失败并出现错误ERROR_CANT_BREAK_TRANSACTIONAL_DEPENDENCY。
这里有一些更多信息NTFS-3G:
备用数据流 (ADS)
NTFS 将所有数据存储在流中。每个文件都有一个未命名数据stream并且可以有许多命名数据streams。文件的大小是其未命名数据的大小stream。默认情况下，ntfs-3g只会读取未命名的数据stream。通过使用选项“streams_interface=windows”（lowntfs-3g 不可能），您将能够读取任何命名的数据流，只需在冒号后指定流的名称即可。例如：
cat some.mp3:artist
命名数据流的行为就像普通文件一样，因此您可以读取它们、写入它们，甚至删除它们（使用 rm）。您可以通过获取“ntfs.streams.list”扩展属性来列出文件具有的所有命名数据流。
要设置它们的用途，您可以使用模块参数：
streams_interface=value
该选项控制用户如何访问备用数据流 (ADS)或者换句话说，named data streams.可以将其设置为“无”之一windows或xattr“.”。如果该选项设置为 none，则用户将无权访问指定的数据流。如果它设置为windows（不可能使用lowntfs-3g），则用户可以像在 Windows 中一样访问它们（例如 cat file:stream）。如果设置为xattr，则指定的数据流将映射到xattrs并且用户可以使用 进行操作{get,set}fattr utilities。默认是xattr在 Linux 上，在其他操作系统上没有。
我想我们可能会因为这个而陷入困境。我认为这可能与我上面读到的内容有关。浏览他们的变更日志，我看到：
ntfs-3g:修复了返回的文件类型readdir()
mkntfs:插入一个$Info stream以$UpCase符合 Windows 8
ntfs-3g:保留 a 的名称deleted file以方便使用undeletion
以上所有内容看起来至少与某些相关删除TNTFS上面文档中提到的问题。
为什么删除文件不会释放磁盘空间？
大多数情况下都是如此，但以下情况除外：
在某些桌面配置中，文件不会被真正删除，而是移动到分区根目录中的
‘Trash’或目录中。‘.Trash-username’当这些目录被清空时，磁盘空间将被回收。按照设计，只有当没有软件让已删除文件继续打开时，Linux 和 Unix 才会永久释放已删除文件的磁盘空间。
NTFS能够以固定大小的(1 kB) MFT记录（索引节点）存储小文件和目录。删除此类文件后，MFT记录将被标记为可重新使用或取消删除，并且无法释放任何空间。
地位：不是NTFS-3G问题。
为什么我无法将文件移至垃圾箱？
仅当垃圾箱目录归当前用户所有时，才可以将文件移至垃圾箱。这意味着通过强制当前用户拥有所有权或使用通用所有权和权限模式，已启用文件所有权。
擦除得到我的投票
如果不擦除磁盘，这看起来不太好 - 这可能不是一个坏主意。如果您可以在 Linux 中访问这些文件，只需备份它们即可。然后获取exFAT驱动程序并使用它 - 这要简单得多，而且，老实说，我开始希望这是分区的事情......
或者也许是固定的？
为什么我在创建文件时收到“不支持操作”的消息？
最新驱动已经解决了这个问题，请升级
老的
这可能有几个原因：
在 Linux 中，你的
ntfs3g驱动程序可以 - 正如我认为你的驱动程序所做的那样 - 显示文件streams.这是文件系统的一个鲜为人知且很少使用的功能NTFS，主要用于shadow copiesWindows 本身保存版本文件。无论如何，结果是有时相同的文件是两个文件。或者更甚。如果您从装载中删除文件ntfs3g而没有正确处理磁盘上的 Windows 类型权限，这可能会变得特别乏味。实际上，您将改变文件'streams.它很令人困惑，这可能就是它不经常使用的原因，但你可以看一下：文件流你的U盘是分区。Windows 不能很好地处理标有 的多分区磁盘可拆卸的flag - 而这是 Unix 方式的重要组成部分。有选项-鲁弗斯和磁盘我能立即想到的有两个。
我说更倾向于之前有第二个问题，但仔细看看你的问题，我认为第一个问题是你的问题。
题外话
当我在 Linux 中构建第一个 Windows 安装映像时，我第一次了解了NTFS文件。streams显然，Windows 安装过程中发生的大部分事情都是在安装过程中将存档streams中的文件转换.wim为常规文件。如果您有兴趣在 Linux 环境中处理这些问题，我强烈推荐wimlib。
我猜有一个第三种可能，也许这就是它：
3.文件或目录丢失、消失？如果顶层目录完全为空，则很可能 NTFS 卷未安装。如果仅丢失某些文件，请至少升级到 NTFS-3G 2009.1.1，它具有完整的内置 Unicode UTF-8 转换支持。
如果您使用 Mac OS X 或 FreeBSD，并且至少有一个包含国家字符的非常长的文件名，并且文件名长度转换为超过 255 UTF-8 字节（韩语和希腊语的可能性更大），则 Mac OS X 和 FreeBSD 将不会显示目录中的任何文件。
如果您使用 Windows 8 进行双重启动，则可能已启用其快速重启功能。这可能会导致 Windows 8 忽略另一个操作系统对任何内部分区所做的更改。避免数据丢失的安全方法是通过以 Windows 管理员身份发出以下命令来禁用快速重新启动：
powercfg /h off
如果您的计算机插入了 SSD，Windows 可能会将其用作由硬件（“Intel 快速响应技术”）或软件（“Expresscache”、“ReadyCache”等）控制的缓存。此功能通常与 Windows 和 Linux 不兼容，您可能必须禁用它。
3:
答案2
只需在驱动器选项中扫描驱动器即可。
不过，您将恢复 NTFS 文件系统中丢失的所有数据。