You know lately I’ve been dealing with Windows, and whilst today I’m not directly impacted I think the case is funny enough on its own.

Today’s problem is corrupt Windows roaming profiles. At Council we get a lot of them. Compared to Defence where two of the help desk guys have worked, its excessive. And today they found the answer: long file names. To explain the problem simply, our document management system creates filenames out of document names and the documents’ unique identifier with underscores and other useful URL friendly replacements being made along the way. So the end result is DOC-12345-Document_Name.doc which is usually fine. However we have instances where the document name is incredibly long. In one particular case this resulted in a filename that was 170 characters long. As these files are typically temporary it doesn’t cause a major issue as the document management system deletes the file when it ferries it off to its own data store, however due to an unfortunate series of events Office’s most recently used list was turned on again (our DM system says it should be off, now for good reason). This meant that Office was creating links (that incidentally go nowhere) to these files – since all that usually means is chopping off whatever extension it has and putting ‘lnk’ on instead, this is a 170 character file that remains in the users profile. So this is dumped into C:\Documents and Settings\username\Application Data\Microsoft\Office\Recent (another 76 characters in this instance, making the complete file name 247 when you include the extra path separator) which then gets synchronised with the users profile.

Now within Windows, the rule of thumb is to keep the entire path under 255 characters otherwise you’ll have issues with the file (see http://support.microsoft.com/kb/q177665/; MAX_PATH was defined as 256 characters, that gives you 255 characters plus a null character), I believe this includes the drive specification as well. It appears that Microsoft expanded MAX_PATH to be 260 at some point (http://msdn.microsoft.com/en-us/library/aa365247.aspx) which is the directory specification, 256 characters of path and a null character. Now it isn’t often that you see a file that long however in this case the document management system can make it occur with reasonable frequency. As the filename is synthesised it doesn’t cause an issue for the document management system (it has its own internal file naming structure that is much shorter), but it causes issues on the client. So we’ve got roaming profiles, which means that file then gets copied to our file servers, in this case they’re Novell boxes. This means to get to where you need to be you start with \\servername\volumeN\ and then you start getting to the actual filesystem. So in our case “\\servername\volumeN\home\username\Windows NT 5.1 Workstation Profile\” is the users roaming profile store. So far so good, thats only another 71 characters…oh wait we’re already hitting the boundaries, if we put the file in that folder it’ll be 241 characters already. The final destination for our file is “\\servername\volumeN\home\username\Windows NT 5.1 Workstation\Application Data\Microsoft\Office\Recent\” – thats 170 character filename plus another 104 characters giving a grand total of 274 character file name. At this point Windows fails to copy the file, errors and corrupts the profile. Interestingly it would appear that some Unicode functions will handle this length path easily, which would suggest that internally Microsoft might not be using those functions for its profile copying. Always good fun.

In more productive news, I reorganised the JCMU repository and uploaded the 1.5 version. I’ve got to do some more work and update myGovernance. Its having issues at the present moment with large files and the connection timing out for some reason. I’m going to shift stuff to my server in the states and then see if I can commit it from there, hopefully this will make a difference. I also did some more training of the helpdesk staff and ended up fielding a rather backwards support request which I’ll quickly share.

Joomla! provides the ability to autocreate users if their user account is valid within an authentication plugin. In our case we use the LDAP plugin so it can autocreate users. Great! But then the web master decided that he didn’t want that because random people were having accounts created because they were valid, but they never should update that website. So autocreate gets disabled. Fast forward a few months and he wonders why a user on the site isn’t being autocreated by Joomla! after its been disabled and files a support incident which I get and wonder what he’s going on about – he was the one in the first place that wanted it disabled. Interestingly there was another strange issue where the system had itself gotten out of sync which some how became my problem. Five minutes editing the user fixed the problem, a job that could have been easily done by helpdesk – I know because I used their account to do it since I don’t have the power to do it myself. This is at least in my area, I got for some reason an incident involving authentication with a proxy server because in the past I’ve done stuff with authentication. Strangely enough the helpdesk person who assigned it to me has more power over the proxy server than I do. Much ado about nothing!