W3C home > Mailing lists > Public > www-lib@w3.org > October to December 1995

RE: W3Lib local file access problem.

From: Maciej Puzio <puzio@laser.mimuw.edu.pl>
Date: Mon, 2 Oct 1995 16:10:15 +-100
Message-Id: <01BA90E1.966A4C20@pclab19.mimuw.edu.pl>
To: "'WWW Library Mailing List'" <www-lib@w3.org>

Teo Kok Hoon wrote:

>    I have been working with the library on the Windows platform for a while and 
>would like to point out one problem I faced with local file access.
>    Looking though the source code (see "HTFile.c", the "HTLoadFile" function), 
>I realise that all local files are opened via a call to
>	fopen( file->localname,"r" );
>My concern is that, for anchors leading to a local file, especially an in-line 
>binary image file, this approach does not correctly complete the fetch of the
>image data. The reason is simple, a binary file is opened as ASCII.

I had similar problems with writing to local files. I am using the library with 
Visual C++ 2.0 on Windows 95.

The HTCacheWriter stream was expanding linefeed characters into CR+LF, 
which caused binary files to be corrupted. The easiest workaround to this problem 
I have found was to link the main program (not the library) with the BINMODE.OBJ 
file. After this all fopen calls (with "w" or "r") open files in the binary mode. 
I suppose this method works for reading from local files too. 

There is however one drawback: text files are opened as binary (so my solution 
doesn't eliminate the problem; it converts it to its opposite :-)). In many situations 
this doesn't matter. For example, many applications for PCs deal correctly with 
text files with LFs only (instead of CR+LF pairs).

Teo Kok Hoon's patch corrects the HTLoadFile function only, so perhaps my 
solution can help people who have problems with writing to files (or with the 
cache). I know it isn't perfect, but it is easy to apply and sufficient in many 

Maciej Puzio
Received on Monday, 2 October 1995 11:09:27 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:33:46 UTC