I am working on a little side project for an old British friend of mine (his name starts with a D and ends with an ean). In the process of working on it I found a bug in AdFind. That bug was based on an assumption, an assumption, on reflection, I really shouldn’t have made. An assumption I made, oh, about a decade ago in one of the very first revs of AdFind and it has been lurking there ever since.
Inside of AdFind there is a small table of hardcoded values for SIDs and GUIDs. This is because initially, that is how I determined what attributes should be handled as SIDs and which should be handled as GUIDs. After a while I got sick of maintaining the table so found some creative ways of dynamically working out what was a SID and what was a GUID; I started reading the schema. Now one problem though, the SIDs have a special attributeSyntax saying they are SIDs, GUIDs are not so lucky. So I perform some basic logic and work out what binary attributes are *possibly* GUIDs[1].
In the meanwhile I left that little hardcoded table in place and it gets loaded every time you start AdFind though mostly it is for when you use –dloid. That switch forces AdFind to NOT load the schema for whatever reason you wanted but I still want to be able to decode certain attributes as SIDs/GUIDs. Now I am reviewing whether or not I still think that is a good idea. In terms of performance, it really doesn’t add any impact, but from the standpoint of “is it a good idea” – that is something that I have to think about.
Anyway the specific issue…. When I built that original table back then I looked at the attribute called oMTIndxGuid which could be up to the size of a GUID structure and had GUID in the name so I assumed it was a GUID. That assumption has gone unnoticed for a decade. Well for whatever reason, I still haven’t figured out why yet, but when querying a directory with the –objfilefolder switch enabled the decoding of that attribute which was previously being incorrectly done as a mostly empty GUID started crashing instead.
Anyway, this assumption will be fixed one way or another in V01.46.00.
joe
[1] Note the same type of issue also exists with INT8 (FILETIME) timestamp attributes. That is also something I am working on for V01.46.00. Actually, I think the fixes there are pretty locked down, it looks for INT8 attributes that have time in the name or adminDescription combined with yes… a hard coded table. Actually there are a couple of tables, one for known INT8 time attributes, one for known INT8 interval attributes. Also there will be a new switch to allow you to specify additional INT8 time attributes as it has been a long time pain for me when I make a new INT8 time attribute and it doesn’t decode that way with my own utility. 
