3

我意识到这可以通过 FileNET P8 API 实现，但是我正在寻找一种方法来查找数据库中的物理文档路径。具体来说，FileStore 中有两个级别的子文件夹，例如 FN01\FN13\DocumentID 但我在任何地方都找不到对 FN01 或 FN13 的引用。

4

2 回答 2

2

您不会在 FN 数据库中的任何位置找到文件夹的名称。文件夹结构由散列函数确定。以下是文件存储页面的摘录：

文档存储在叶级别的目录中，使用散列算法在这些叶目录之间均匀分布文件。

于 2015-08-13T09:54:52.253 回答
0

IBM 的回答仅从预期功能的技术角度来看是正确的。

如果您确实需要查找文档文件名和文件夹位置，请通过使文件存储文件夹对 Content Engine 不可用来禁用您的实际文件存储。我通过简单地将根 FN# 更改为 FN#a 来为每个文件存储做到这一点。例如，FN3 变成了 FN3a。完成后，我将顶部树文件夹改回来。我使用了该方法，因此日志文件不会超过该工具的最大输出。任何使存储位置（例如：驱动器、共享等）可访问和可搜索但使单个文件不可用的方法都应导致相同的结果。

然后，运行内容引擎一致性检查器。它将为您提供所有文件、ID 和位置的完整列表。

之后，您可以将条目与数据库表中的 OBJECT_ID 字段进行匹配。在非 MSSQL 数据库中，UUID 的前几个八位字节的字节顺序是相反的。您需要考虑这一点并修复字节顺序以匹配 CCC 输出。

...需要进行字节反转，以便可以在 Oracle 中查询。在查询 GUID 时，GUID 在 Oracle 和 DB2（不是 MS SQL）中以字节反转的形式存储，其中前三个部分成对反转，后两个部分保持不变。

因此，反过来同样适用。为了使用 Content Consistency Checker 的输出将输出与数据库匹配，必须进行相同的字节顺序反转。

有关详细信息，请参阅此 IBM 技术文档和下面链接的答案：

有关存储机制的更多详细信息位于此处：

我不建议将其用于任何灾难性需求，例如重建和重写整个文件存储，当您的前任破坏 NTFS（或类似的令人讨厌的情况）时，该文件存储被您的前任严重破坏。

这是绕过 FileNet 的散列的一种解决方法，该散列用于混淆查看文件系统的人的内容信息。

于 2017-05-22T18:53:08.363 回答