Like many Revelation consultants, we have a number of clients who continue to use decades old software under new, more modern technologies - specifically AREV32/64. A technology that was meant to provide a transition path to a more modern UI is frequently just used as a way to continue taking advantage of the massive ROI provided by Revelation Software - in this case AREV.

But sometimes, things go wrong. And this week we were bitten by a particularly pernicious bug that we hadn't seen before.

The client reported that suddenly, blank documents were being emailed to their customers rather than the order confirmations that they were expecting. Investigation was relatively easy - isolate the section of the code that creates the files and test this. The section of code in question simply executed a PDISK to redirect printer output to a file, produced the report, then PDISK PRNed to cancel the redirection.

Upon testing, it failed to produce any output, despite reporting that the redirection was successful. Following Occam's Razor we tried to reproduce the issue by issuing a PDISK at TCL, performing a simple LIST report to disk, then doing a PDISK PRN. Surprisingly, no disk file was produced. 

So we reverted to an older version of the software and tried again - regretfully with the same result. It didn't matter how far back we went, the error persisted. At this point it became obvious that this was not the issue that the client was facing - all had been well until the last upgrade - but it WAS an issue that we were facing in our testing. But our software was a direct copy of their system, so what could it possibly be?

We tried calling SETPTR directly, we tried different filenames and different extensions but to no avail. So it was time to roll out the big guns and deploy PROCMON, the stunningly useful utility from SysInternals available from Process Monitor - Windows Sysinternals | Microsoft Docs. We reproduced the lack of output with PROCMON running and examined the captured output. We filtered the output on process OENGINE.EXE and path containing ZZZZ.txt and saw 6 entries as below :-

The first 4 were as expected, but the last two were strange to say the least. The spaces in our directory path had been replaced with underscores - and strangely, Windows could not find a path with that name.

This provided us with a working theory - so we copied the system to a subdirectory with no spaces in the name and repeated the experiment. This time we saw the results we expected - a file containing output :-

and the PROCMON trace showed no errors

So it would seem that PDISK has been engineered not to work with subdirectories containing spaces in the path.