While installing LibraryLink and ThumbsPlus with a local authority client yesterday, we hit DFS problems immediately – images un-cataloguing themselves before our eyes, and thumbnails not appearing for users on other machines. DFS, or Distributed File System, is a Microsoft technology for presenting multiple physical drives as single logical drives, as explained here.

We found a workaround that appears to solve this, but it is not bombproof, and requires great care. The better solution is probably for IT to label all DFS volumes consistently, as explained below, though this is only a hypothesis not proven yet (others may know better?).

We discovered that different machines were seeing different underlying physical volumes as the same logical volume, and that these DFS volumes had not been given volume labels. We can confirmed the use of DFS by viewing the properties of the network drive – there is a DFS tab, as shown below:

The volume label (or absence thereof) can be checked on the General tab of the properties:

In this case the label of the physical DFS drive is 439, but on the physical volumes we were working with it was blank.

The absence of matching labels on the physical volumes making up one logical volume causes ThumbsPlus not to consider them the same volume, as it uses the label to match database volumes to physical (or rather logical) volumes. When the label is blank, it uses a version of the volume serial number as a label.

The symptom is that files that have been catalogued will appear as thumbnails to one user, and un-catalogued files to another (white with red cross). Files may even go from being catalogued to un-catalogued and back again during the same session.

Solutions?

The best solution would probably be for IT to assign consistent volume labels to the various physical volumes that make up each logical volume, so they all appear the same to ThumbsPlus. For example “BorsetshireCC_Data” or something. This should have no effect on other systems, which cannot be relying on the volume labels at present (because they are empty). But in our case this was not going to be possible within useful timescales.

We developed an interim workaround as follows.

First we scanned at least one thumbnail on each of the machines that we new were seeing a different physical volume (once the problem had been identified). This resulted in two records in the [Volume] table in the ThumbsPlus database. We then renamed the [Volume] table to [VolumeReal], and create a query called Volume with this SQL:

SELECT 1 AS idVol, VolumeReal.vtype, VolumeReal.serialno, VolumeReal.maxcomplen, VolumeReal.vchar, VolumeReal.filesystem, VolumeReal.label, VolumeReal.netname, VolumeReal.alias

FROM VolumeReal;

The presents the two different Volume.Label values as the same volume ID=1, which fools ThumbsPlus into seeing the two physical volumes as one database volume again.

The “1” value in the first volume was an arbitrary choice of one of the existing volumes.

It is import to remove any thumbnails and paths that are associated with volumes other than the one chosen.

We do not know at present whether other physical volumes are present. If they are, then this solution will break down temporarily. To help identify this, we configured ThumbsPlus to open at a specific folder, where it will be immediately obvious to the user if thumbnails have apparently become un-catalogued.

If this arises, the procedure for adding the new physical volume to the “solution” is:

1. In ThumbsPlus right click on the root of the drive (P) and open the Properties. Take a note of the serial number, which should be a string of numbers and possibly letters (my guess it is a hexadecimal number).
2. Then open the TD4 database in MS Access.
3. Open the VolumeReal table, and copy and paste a record. In the new record, change the [label] value to the noted value, preceded by a #. Leave other fields unchanged.
4. On restarting ThumbsPlus, the thumbnails should reappear.

Note that if our client’s IT folk can implement the better fix of assigning matching labels to physical volumes making up the logical volume behind the P drive (\\dxxx123etc.ds.borsetshire.gov.uk\blahetcDFSLink$) this will in turn break our catalogue, because the labels will no longer match.

If and when this arises, the solution then would be to find out the new label value, and amend the record in the Volume table with ID=1 to use the new label (taking a backup of the database before this). If this works to mend the catalogue, then it should be fine to drop or rename the Volume query, and reinstate the Volume table.

Note: all of the above applies when ThumbsPlus is set in the mode where volume identification options have “Match network volumes using share name” set to False, as shown below. This means that volume matching uses the volume label only.  With this set to True, cataloguing on the network drives did not work at all, and folders with catalogued contents would only appear under “Offline Network”. With “Match network volumes using share name” set to True, it still apparently requires a match on the volume label, before going on to check the sharename, so the same fix should apply.