3

I realize this is possible with the FileNET P8 API, however I'm looking for a way to find the physical document path within the database. Specifically there are two level subfolders in the FileStore, like FN01\FN13\DocumentID but I can't find the reference to FN01 or FN13 anywhere.

ﾤ ﾡ
  • 5,669
  • 6
  • 43
  • 57
Ryan Leeper
  • 53
  • 1
  • 3

2 Answers2

2

You will not find the names of the folders anywhere in the FN databases. The folder structure is determined by a hashing function. Here is an excerpt from this page on filestores:

Documents are stored among the directories at the leaf level using a hashing algorithm to evenly distribute files among these leaf directories.

Robert Mugattarov
  • 1,278
  • 2
  • 12
  • 26
  • 1
    The physical name of the file does contain the ID of the document in the DB. So if you really want this you'd have to manually 'index' you filestores. I had to do this once, I used a program that creates an xml printout of a directory structure. Then I built an application that processes the file and builds a database that holds the ID and the name/location of a file. I know its a hassle and cumbersome but if you really need this, this is a way to do it. – Robert vd S Aug 27 '15 at 11:55
  • @RobertvdS Do you happen to know, how Filenet "calculates" in which folder a specific document id gets stored ? – Marged Jun 25 '18 at 19:23
  • I do not know how the ce calculates this, I created a program that crawled through the actual files of the filestore and wrote the full path and doc id to a db table. – Robert vd S Jul 02 '18 at 06:50
0

The IBM answer is correct only from a technical standpoint of intended functionality.

If you really really need to find the document file name and folder location, disable your actual file store(s) by making the file store(s) folder unavailable to Content Engine. I did that for each file store by simply changing the root FN#'s to FN#a. For instance, FN3 became FN3a. Once done, I changed the top tree folder back. I used that method so log files would not exceed the tool's maximum output. Any method that leaves a storage location (eg: drive, share, etc) accessible and searchable, but renders the individual files unavailable should cause the same results.

Then, run the Content Engine Consistency Checker. It will provide you with a full list of all files, IDs and locations.

After that, you can match the entries to the OBJECT_ID fields in the database tables. In non-MSSQL databases, the byte ordering is reversed for the first few octets of the UUID. You need to account for that and fix the byte ordering to match the CCC output.

...needs to be byte reversed so that it can be queried upon in Oracle. When querying on GUIDs, GUIDs are stored in byte-reversed form in Oracle and DB2 (not MS SQL), whereby the first three sections are pair reversed and the last two are left alone.

Thus, the same applies in reverse. In order to use the output from the Content Consistency Checker to match output to database, one must go through the same byte ordering reversal.

See this IBM Tech Doc and the answer linked below for details:

More detailed information on the storage mechanisms is located here:

I do not suggest using this for anything but catastrophic need, such as rebuilding and rewriting an entire file store that got horrendously corrupted by your predecessor when they destroyed an NTFS (or some similarly nasty situation).

It is a workaround to bypass FileNet's hashing that's used to obsfucate content information from those looking at the file system.

Robert Mauro
  • 566
  • 8
  • 17