Mar*_*iaz 7 storage troubleshooting usb-drive
我的 U 盘有点问题。我可以在 Linux 机器 (Fedora 20) 上查看和操作 U 盘上的文件和文件夹，但是在 Windows 机器上使用 U 盘时，其中一些文件和文件夹无处可见。此外，根据 Windows，USB 记忆棒上存储了近 2.9 GB 的文件，但我可以使用的文件只有 500+ MB。我不知道为什么会发生这种情况，但这不是第一次。我该怎么做才能永久解决这个问题？
所以，我真的不认为我NTFS今天早上会研究，但是，主要感谢@AndrewMedico 在下面的评论，我学到了一些东西。
事实是文件streams很奇怪，它们让我感到困惑，但显然它变得更深了。行为方式与NTFSfile非常相似streams，Transactional NTFS将文件更改提交到某个备用缓存，直到更改得到保证。当它是时，文件被原子地和完全地提交到一个文件中。我混淆了文件的概念stream- 我仍然认为它必须是一个非常相似的概念，并且可能以某种方式涉及，因为每个文件可以有多个named而且只有一个unnamed streams- 显然正在发生的事情TNTFS.我想我不是唯一的一个：
由于其复杂性和开发人员在应用程序开发过程中需要考虑的各种细微差别，Microsoft 正在考虑在 Windows 的未来版本中弃用 TxF API。因此，Microsoft 强烈建议开发人员调查使用替代方案，而不是采用
Transactional NTFS未来版本的 Windows 中可能不可用的API 平台。
当我将下面提到的那个 Windows 映像放在一起时，我遇到了文件消失、重新出现的问题 - 似乎甚至在完全删除磁盘之后 - 这实际上主要是截断了它。我当时的理论是——现在仍然是部分——Linux 缓存没有提交对文件的更改streams。我现在认为它只是没有以预期的方式处理原子提交：
通过调用该
DeleteFileTransacted函数删除的文件或目录对所有外部读者仍然可见。*注意 所有*交易
handles到文件必须在结束之前关闭transaction。如果handles未正确关闭，delete则不会发生。在执行commit删除操作之前，必须关闭文件的所有打开句柄，以便将其视为事务的一部分。这是因为作为 Windows 文件 I/O 子系统的一部分，系统不会真正删除文件，直到它的最后一个句柄关闭，即使操作没有被处理。
通过调用该
RemoveDirectoryTransacted函数删除的目录对所有外部读者仍然可见。
如果在事务中修改了文件，则该文件路径的所有目录组件都将被锁定以防止重命名，直到事务结束。也就是说，在事务提交或回滚之前，系统会阻止您重命名它们。尝试重命名作为已在正在进行的事务中修改的文件的祖先的目录将失败并显示错误ERROR_CANT_BREAK_TRANSACTIONAL_DEPENDENCY。
这是来自NTFS-3G 的更多信息：
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记录（inode）中。当此类文件被删除时，这些MFT记录将被标记为空闲以供重用或取消删除，并且无法释放任何空间。
状态：不是 NTFS-3G 问题。
为什么我不能将文件移到回收站？
只有当当前用户拥有垃圾目录时，才能将文件移动到垃圾箱。这意味着已启用文件的所有权，通过将所有权强制给当前用户或使用通用所有权和权限模式。
如果没有擦除磁盘，这看起来不太好 - 这可能不是一个坏主意。如果您可以访问 Linux 中的文件，只需备份它们。然后得到exFAT驱动程序并使用它 - 它更简单，而且，老实说，我开始希望它是分区的东西......
或者也许它是固定的？
为什么在创建文件时会收到“不支持操作”消息？
最新驱动已解决此问题，请升级
这可能有以下几个原因：
在 Linux 中，您的ntfs3g驱动程序可以 - 正如我认为您的那样 - 显示文件streams.这是NTFS文件系统的一个鲜为人知且很少使用的功能，主要用于shadow copiesWindows 本身保存的版本文件。反正结果就是有时候同一个文件就是两个文件。或者更甚。如果您在ntfs3g没有正确处理磁盘上的 Windows 类型权限的情况下从装载中删除文件，这会变得特别乏味。实际上，您将更改文件的streams. 这很令人困惑，这可能就是为什么它不经常使用的原因，但是在这里：文件流
您的 U 盘已分区。Windows 不能很好地处理标有可移动标志的多分区磁盘- 而这都是 Unix 方式的重要组成部分。有很多选择 - Rufus和ImDisk是我能想到的两个。
我说更有可能之前，但仔细看看你的问题，我认为第一个是你的问题。
当我在 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 用作由硬件（“英特尔快速响应技术”）或软件（“Expresscache”、“ReadyCache”等）控制的缓存。此功能通常与 Windows 和 Linux 不兼容，您可能必须禁用它。
3 :