Page 1 of 1

PDF written to network contains all zeros 0x00

Posted: Mon Jun 20, 2005 3:17 pm
by Carl
Customer installed some new XP patches this AM and now writing PDFs to a network drive writes all zeros to the file. Writing to C:\ works correctly. The network file 130Kb size is about the same as the C: file at 138Kb, but every single byte is 00.

Patch was KB 883939. Customer uninstalls and PDFs work again.

wondered if you had any guess as to what this could be?

Posted: Mon Jun 20, 2005 5:37 pm
by John - Tracker Supp
Sorry Carl,

not a clue and have had no other reports - could it be some sort of rights issue ?

Posted: Tue Jun 21, 2005 5:54 am
by John - Tracker Supp
Hi Carl,

just thinking further on this - :

can your user see the Network drive when mapped from the PDF-XChange 'PrintingPreferences'


If he has not installed the driver - is it possible he could do so to test ?


Tests completed

Posted: Wed Jun 22, 2005 10:32 pm
by Carl
User set me up a new PC with patches installed and reinstalled my software. Confirmed bug with printing to network driver still exists. He has it on several PCs. Another customer has it.

Installed PDF XChange 3.0 driver. Went to 'PrintingPreferences'
->Save->UsePredefinedValues->Browse and could see network drive N: just fine. Set to print to network N:\test with file name [%date][%time]. Used this setup to print from my software to network drive and got all 00's in PDF.

Printed from WordPad to network drive and also got all 00's. Changed to print to C:\ and it worked.

Wanted to try using your Test_xMF but it always writes to c:\. is there a switch to change destination?

I grabbed an MSInfo32 dump of his system info and attached it.

All testing was done with the 6/18/05 DLLs.

Posted: Thu Jun 23, 2005 11:29 am
by John - Tracker Supp
Thanks - looking into.

Posted: Thu Jun 23, 2005 11:30 am
by Carl
A Clarion COPY() of a file works just file, and other Clarion file operations work fine.

Posted: Thu Jun 23, 2005 11:37 am
by John - Tracker Supp
OK - Thanks :)

Posted: Thu Jun 23, 2005 1:08 pm
by rmcmanamy
We have the exact same results with a customer of ours. I had to write them a VB wrapped to always save the file to the local C: temp directory when they print through the driver and then I prompt them for the filename and copy it over to the network drive when it's finished.

Any update on this

Posted: Wed Jul 20, 2005 12:20 pm
by Carl
Any update on this? Is it reproducable by you?
I'll fix by writing to c:\temp then copy to destination, but it causes a slight snag with the preview option since I do not want the c:\temp copy to be opened for preview

Posted: Wed Jul 20, 2005 2:31 pm
by John - Tracker Supp
Hi Carl,

at this time we cannot reproduce - which is making it very hard to track down and resolve - though we do accept the issue exists - we have no idea at this time why. :(

Posted: Wed Jul 20, 2005 3:32 pm
by Carl
One feature/workaround you could implement would be a library option to write PDF work files to the Windows Temp Directory, then on closing Copy the completed file to the final destination and open for preview.

Helps with the situation that "Networks are like a box of chocolates, you never know what you're going to get"

This could offer performance benefits as random IO writing to a local hard drive can be faster. Especially in slower WAN type situaitons.

One other benefit is if anything fails in the PDF library an incomplete and corrupt PDF file is not left where the user is expecting it. For some that might cause some difficulty as it will be hard to find the incomplete file. For me I do not want invalid files available to end users. Invalid files from your library have not been a problem ever.

So the TempWriteFIle option I would suggest is
0=No temp file, Write to destination (default)
1=Write to Temp directory, then copy to destination
2=Write to Temp directory only if it is on a different drive letter (or check for Local Drive), then copy to destination

Posted: Thu Aug 04, 2005 9:26 am
by John - Tracker Supp
Hi Carl,

we have written this test app in-house to try and get a handle on this problem - would appreciate if it could be tested on a problem site and let us know the outcome



1. Unzip archive into any folder.
2. Run TestFileMapping.exe from the command line with the destination path as a parameter. Here is an example of valid command lines:

TestFileMapping "C:\My Documents"
TestFileMapping \\server\share\

The utility Program will create a set of test text files and verify them. if an error occura it will be displayed on screen and also logged.

3. Collect the file log.txt from the folder where TestFileMapping.exe was unzipped and files test_?_?.txt from the destination folder, zip all and please to send us.

To manually verify if everything was OK you may check the files manually - they should contain variable length lines of 0, 1, 2, etc characters.

all files test_0_?.txt should be indentical and so on.

If you wish to run the test app several times you must take care as each log file with each new execution will be overwritten

Many thanks