Since I spent some time working with the File Tracker, I thought I would write how it really works. This is useful to know:

• what can be manually done with the files without preventing the File Tracker to work
• what can be done when downloading file via ICN, especially sub-folders speaking

Principle

The File Tracker applet will use the desktop’s configuration to know what is the File Tracker directory. That can be an environment variable, user home directory, user document directory, or a hard defined folder. Then it will download all documents in this folder, and will be able to find them back for the check in. That way, the user does not have to give the file himself when checking in.

How the FileTracker store and retrieve files

By default, the ICN FileTracker download all documents in its root folder, there is no hierarchy mirroring from the Object Strore like there was with Workplace XT. However, one can change the download folder in the Check out and Download dialog and use an existing folder, and the File Tracker will still find the document. So how does it work?

There is actually two tracker systems. The UD based tracker, and the file attribute tracker. The first one is used first, then if it fails, the second is used as a backup. We’ll see why later.

The UD based tracker

This system uses the hidden folders with strange names that are created in the root folder, for instance .b3c9f8a743c47d3665f87e92991b57ff. The name of the folder is actually a hash of a mix of the repository, version series id and version id. That means that a new version won’t be bind to the existing file if you left it on your file system after checking in. In this folder, you can find an icnFInfo.properties file. This is the file actually containing information about the location. It looks like:

#last update time : 1434015511664
#Thu Jun 11 11:38:31 CEST 2015
versionSeriesId={D2AEEF1F-4372-4594-8EAD-F2BC94FC20BA}
objectStoreName=RCHOS2
objectId=IBM_IBMIDDoc,{250AEFD6-4B95-4C34-947C-639E32BD63AD},{EB556307-F3E8-4D73-8C24-4131C6D8490C}
filePath=C\:\\FileNet\\Work\\Current\\TARGETOS\\DitaToolsTeam\\Guillaume\\A\\batcleaning.ide

The UD based tracker is really fast since it looks only for one folder then read one file in it. This is why it’s the first used system by the File Tracker applet.

The File Attribute based tracker

This system uses something quite advanced and new in the workstation File System and the Java world (that came with the nio package). if the file system supports it, it uses user defined file attributes ( bind to the class java.nio.file.attribute.UserDefinedFileAttributeView). to store information about the document in FileNet. Implementation varies, depending on the OS.

It actually stores an XML string in a custom file attribute named FnADS. The XML stream looks like this:

<?xml version="1.0"?>
<!--This XML file created by ICN File Tracker.-->
<AlternateDataStream>
	<Record>
		<ClientID>C:\FileNet\Work\Current\TARGETOS\DitaToolsTeam\Guillaume\A\batcleaning.ide</ClientID>
		<ObjectStoreName>RCHOS2</ObjectStoreName>
		<VersionSeriesID>{D2AEEF1F-4372-4594-8EAD-F2BC94FC20BA}</VersionSeriesID>
		<VersionID>IBM_IBMIDDoc,{250AEFD6-4B95-4C34-947C-639E32BD63AD},{EB556307-F3E8-4D73-8C24-4131C6D8490C}</VersionID>
		<ClassName>IBM_IBMIDDoc</ClassName>
	</Record>
</AlternateDataStream>

And therefore, with this system, there is no need for external data kept somewhere else, in another file or a database. This is quite smart but the big downside is that the File Tracker needs to analyze all files in the File Tracker folder (and sub-folders if any) to find the right file. This is really slow, but the upside is that if a user deletes by mistake all the UD hidden folders, the File Tracker will still be able to find the tracked file.

This system checks that etither the Object Store is and the version series are the same, that means unlicke the UD based tracker, this method can find the file either if the version changed.

But, this is really unstable, because some editor remove the alternatives streams when saving the document, so if you modified the file from an old version, for instance you checked out and DL, modified, check in without deleting, check out only and you are using the file on your file system to modify, the check in will find the file only if your editor preserve the alternative stream. Notepad keeps the ADS, notepad++ does not.

Note: there is a bug with this system and empty folders, see this post if interested.

Implementation on windows: That’s no easy task to see this user file attributes on windows (NTFS). They don’t use the standard File Attribute system since it does not support custom attributes. Instead, it uses the Alternate Data Steams in NFTS (ADS), with a stream named FnADS (hence the name 🙂 ). You can’t see them from the Windows Explorer. One easy way to see them is to use PowerShell 3+ (not 2, stream option does not exist), and use the command get-content with the stream option.

What can we conclude

• You can use sub-folders if users want to organize better documents in the File Tracker folder, it will still be able to retrieve files. It can even be done automatically via a plugin to reproduce the Workplace XT behavior, but you will have to get an applet creating the folder or the download method of the File Tracker will fail.
• That’s not so much a big deal if a user deletes (by mistake or not because I have to say that’s really annoying if you don’t hide hidden files) the UD hidden folders (starting with a dot), because the File Tracker applet is able to find the document using a custom file attribute.