问题标签 [fat]

如何以编程方式访问 Windows 中的文件分配条目 (FAT)？我已经阅读了提到在硬盘中特定地址读取条目的文章，但是我如何从硬盘中读取这些条目。我可以尝试使用 C、C++、C# 或 VB。

http://www.ntfs.com上的教程有助于理解在 FAT 上阅读的内容，但没有阐明如何以编程方式进行。

我正在浏览这个链接：FAT16 Basics to Assemble Clusters。我已经阅读了在 FAT 中定义目录条目所涉及的结构。现在在给出 FAT16 文件的示例时，它表示示例文件 MyFile.txt 的数据簇为 0x03。这意味着如果我们在逻辑上计算数据集群，我们将能够到达第一个节点，该节点恰好是 3 号集群。

但我无法理解的是作者在下一行中试图说的内容

此时我们可以在文件分配表中看到什么？

我们如何突然到达文件分配表？当我们浏览Myfile.txt的信息时，我们不是已经在那里了吗？我找不到任何原因，作者突然跳到偏移位置 00000200 并识别集群的空虚。如果有人可以帮助我理解，那就太好了。

我需要查询文件夹结构。换句话说，我需要能够通过 SQL 访问目录结构。我在想应该有一些 OLE DB 提供程序或一些 ODBC 驱动程序用于此目的。我的朋友对谷歌说“文件夹监控”，但我什么也找不到 我需要像资源管理器一样实时访问它。有办法吗？谢谢

我最近遇到了一个嵌入式系统，它的 IDE 驱动器是 FAT32，但文件>4gb。它似乎通过将 32byte 目录条目中的文件大小设置为最终集群使用的字节数来实现这一点 - 而不是实际的文件大小。这允许文件具有任意 FAT 链。不利的一面是知道文件大小的唯一方法是流过巨大的链。

我以前从未见过这种情况。这是一个已知的标准或变体，Windows 或 linux 上是否支持它？

是否有任何“古怪”的 FAT32 修改更标准，允许文件大于 4GB？

我想通过其哈希搜索文件重复。出于性能目的，我想知道 NTFS/FAT 文件系统中的每个文件是否都存储了哈希/校验和。如果有，我不必全部计算它们来搜索我的文件。

如果有，如何使用 .NET 访问它？

如果有帮助，它将是 JPEG 文件。他们有校验和吗？

我们在 WinCE 5.0 上基于闪存的 FAT 文件系统上的损坏文件存在严重问题。我们认为文件已损坏是因为 WinCE 设备在写入 FAT 时关闭。因此，我们改为 T-FAT（事务性 FAT）。

验证我们的问题是否已解决的最省时的方法是什么？

我一直在阅读有关“胖控制器”的文章，但那里的大多数文章都侧重于将服务/存储库层逻辑从控制器中拉出来。但是，我遇到了不同的情况，想知道是否有人有任何改进的想法。

我有一个操作太多的控制器，我想知道如何将其分解为多个操作更少的控制器。所有这些操作都负责插入/更新/删除都属于同一聚合的对象。所以我并不热衷于为属于这个聚合的每个类拥有一个单独的控制器......

为了提供更多详细信息，此控制器用于选项卡式页面。每个选项卡代表要编辑的数据的一部分，这里使用的所有域模型对象都属于同一个聚合。

有什么建议吗？

干杯，莫什

给定以下 BPB：

FAT32 BPB http://img121.imageshack.us/img121/1131/fat32bpb.png

“MSWIN4.1”字符串只是“OEM ID”字段，根据 Microsoft 文档，它不应用于识别 FAT 卷。

“FAT32”字符串是 BS_FilSysType 字段，根据 Microsoft 文档，它也不应该用于识别 FAT 卷。

那么如何确定该卷已格式化为 FAT？有什么可靠的签名可以转发吗？

我的任务是为Unitech HT630编写一个数据收集程序，它运行一个专有的 DOS 操作系统，可以运行为 16 位 MS DOS 编译的可执行文件，但有一些限制。我正在使用 Digital Mars C/C++ 编译器，它目前运行良好。

应用程序要求之一是数据文件必须是人类可读的纯文本，这意味着文件可以导入 Excel 或用记事本打开。我使用的可变长度记录格式很像 CSV，我已经使用 C 标准库文件 I/O 函数成功实现了这种格式。

保存记录时，我必须计算更新后的记录是大于还是小于数据文件中当前记录的版本。如果更大，我首先将当前记录之后的所有记录向前移动，按保存更新记录之前计算的大小差异。操作系统会自动扩展 EOF 以容纳额外的数据。如果更小，我将所有记录向后移动我计算的偏移量。这很好用，但是我发现无法修改 EOF 标记或文件大小以忽略最后一条记录结束后的数据。

大多数情况下，记录的大小会增加，因为数据收集程序会在保存记录时用数据填充一些空白字段。仅当对现有条目进行更正时，记录的大小才会缩小，或者如果记录中的描述性数据长于程序在内存中读取的数据，则在正常记录保存时会缩小记录的大小。

在记录缩小的情况下，在文件中的最后一条记录之后，我留下了班次之前坐在那里的任何数据。在“缩小记录保存”之后，我一直在文件中写入一个 EOF 分隔符，以指示我的记录的末尾在哪里并填充剩余数据的空间，但是在“增长记录保存”之前我不再有一个干净的文件在空间填充区域上扩展文件的大小。中的truncate()功能unistd.h不起作用（我现在认为这仅适用于 *nix 口味？）。

我见过的一个提议的解决方案涉及创建第二个文件并将您希望保存的所有数据写入该文件，然后删除原始文件。由于我只有 4MB 的磁盘空间可供使用，因此如果文件大小小于 2MB 减去我的程序可执行文件和配置文件的大小，则此方法有效，否则会失败。很有可能当它投入生产时，用户最终会得到一个超过 2MB 的文件。

我查看了Ralph Brown 的中断列表和IBM PC 汇编语言和编程中的中断参考，我似乎找不到任何可以更新文件大小或类似内容的东西。

在 DOS 中甚至可以在不创建第二个文件的情况下减小文件的大小吗？

Reiser、NTFS 等文件系统在哪里存储文件表？我们正在考虑编写我们自己的文件系统，并且想知道我们是否应该使用单个文件来使用 btree 来保存它，或者使用其他东西。

有什么建议吗？这比任何事情都更像是一种学习练习。

编辑：删除 NFS，并替换为 NTFS