Date: Wed, 30 Nov 2005 00:04:23 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600
Subject: [UnixOS2_Archive] No. 655

**************************************************
Tuesday 29 November 2005
 Number  655
**************************************************

Subjects for today
 
1   strange behaviour with file read : Dave Bamford <dave at logical-progress.com>
2  Re:  strange behaviour with file read : Dave Yeo" <dave_yeo at paralynx.com>
3  Re:  strange behaviour with file read : Jon Saxton <js at triton.vg>
4  Re:  strange behaviour with file read : Dave Bamford <dave at logical-progress.com>
5  Re:  strange behaviour with file read (solved) : Dave Bamford <dave at logical-progress.com>
6   OT apache .htaccess logs : Dave Saville" <dave at deezee.org>
7  Re:  strange behaviour with file read : Stefan.Neis at t-online.de" <Stefan.Neis at t-online.de>
8  Re:  OT apache .htaccess logs : IanM" <IanM>
9  Re:  OT apache .htaccess logs : IanM" <IanM>


**= Email   1 ==========================**

Date:  Mon, 28 Nov 2005 22:15:15 +0000
From:  Dave Bamford <dave at logical-progress.com>
Subject:   strange behaviour with file read

I have got a problem with porting some code.
It reads data from a file into memory, the filesize as reported by "dir" 
is 218 bytes
and this is passed to this routine

int FileStream::Read(void *pBuffer, int NBytes, int Timeout)
{
    if(mOSFileHandle == -1) {THROW_EXCEPTION(CommonException, FileClosed)}
    int r = ::read(mOSFileHandle, pBuffer, NBytes);
    if(r == -1)
    {
        THROW_EXCEPTION(CommonException, OSFileReadError)
    }
    if(r == 0)
    {
        mIsEOF = true;
    }
   
    return r;
}

BUT only 215 is returned. The clue is that there are 3 lines of text in 
the file and
I think the EOLs are not being counted. If I print out pBuffer all the 
data is there
inc the EOLs.

gcc version is...
gcc --version
gcc (GCC) 3.3.5 (Bird Build 2005-11-17 03:47)


Dave Bamford.



**= Email   2 ==========================**

Date:  Mon, 28 Nov 2005 17:42:37 -0800
From:  "Dave Yeo" <dave_yeo at paralynx.com>
Subject:  Re:  strange behaviour with file read

On Mon, 28 Nov 2005 22:15:15 +0000, Dave Bamford wrote:

>I have got a problem with porting some code.
>It reads data from a file into memory, the filesize as reported by "dir" 
>is 218 bytes
>and this is passed to this routine
>
>int FileStream::Read(void *pBuffer, int NBytes, int Timeout)
>{
>    if(mOSFileHandle == -1) {THROW_EXCEPTION(CommonException, FileClosed)}
>    int r = ::read(mOSFileHandle, pBuffer, NBytes);
>    if(r == -1)
>    {
>        THROW_EXCEPTION(CommonException, OSFileReadError)
>    }
>    if(r == 0)
>    {
>        mIsEOF = true;
>    }
>   
>    return r;
>}
>
>BUT only 215 is returned. The clue is that there are 3 lines of text in 
>the file and
>I think the EOLs are not being counted. If I print out pBuffer all the 
>data is there
>inc the EOLs.

What about reading it binary instead of text? quick hack is -Zbin-files
Dave



**= Email   3 ==========================**

Date:  Tue, 29 Nov 2005 00:36:32 -0500
From:  Jon Saxton <js at triton.vg>
Subject:  Re:  strange behaviour with file read

Is this code executing on a DOS, OS/2 or Windows platform?  If so then 
I'd say CR-LF pairs are being translated to LF on input.

There are several workarounds.  One is to read the file in binary mode 
as Dave Yeo suggests but you'll get the carriage returns in your data 
which may not be what you want.  Another is to pre-strip carriage 
returns from the file using any of several programs which exist for that 
purpose.  A third option is to recognise the cause and ignore the 
discrepancy.


Dave Bamford wrote:

> I have got a problem with porting some code.
> It reads data from a file into memory, the filesize as reported by 
> "dir" is 218 bytes
> and this is passed to this routine
>
> int FileStream::Read(void *pBuffer, int NBytes, int Timeout)
> {
>    if(mOSFileHandle == -1) {THROW_EXCEPTION(CommonException, FileClosed)}
>    int r = ::read(mOSFileHandle, pBuffer, NBytes);
>    if(r == -1)
>    {
>        THROW_EXCEPTION(CommonException, OSFileReadError)
>    }
>    if(r == 0)
>    {
>        mIsEOF = true;
>    }
>      return r;
> }
>
> BUT only 215 is returned. The clue is that there are 3 lines of text 
> in the file and
> I think the EOLs are not being counted. If I print out pBuffer all the 
> data is there
> inc the EOLs.
>
> gcc version is...
> gcc --version
> gcc (GCC) 3.3.5 (Bird Build 2005-11-17 03:47)
>
>
> Dave Bamford.
>
>
>
>


-- 
Jon Saxton <js at triton.vg> Shopkeeper, Numismatist-in-training
Developer of cross-platform software for UNIX, OS/2 and Windows
U.S. Agent for Triton Technologies International Ltd
http://www.triton.vg/




**= Email   4 ==========================**

Date:  Tue, 29 Nov 2005 08:12:42 +0000
From:  Dave Bamford <dave at logical-progress.com>
Subject:  Re:  strange behaviour with file read

This is a multi-part message in MIME format.
--------------080008030204070608090801
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit

Its running on an OS2 platform, I am porting boxbackup, an online backup 
program so the
files must be read exactly (ie I want to preserve the CF LF pairs)
AFAIK there are no workarounds needed on a linux platform or with the 
win32 port
(there may be but I can't find them).
I have contacted the developer and he may help

I have tried looking at the gcc source to find out if ::read should 
strip CRLF to CR only
but I can't find this out.

Dave

Jon Saxton wrote:

> Is this code executing on a DOS, OS/2 or Windows platform?  If so then 
> I'd say CR-LF pairs are being translated to LF on input.
>
> There are several workarounds.  One is to read the file in binary mode 
> as Dave Yeo suggests but you'll get the carriage returns in your data 
> which may not be what you want.  Another is to pre-strip carriage 
> returns from the file using any of several programs which exist for 
> that purpose.  A third option is to recognise the cause and ignore the 
> discrepancy.
>
>
> Dave Bamford wrote:
>
>> I have got a problem with porting some code.
>> It reads data from a file into memory, the filesize as reported by 
>> "dir" is 218 bytes
>> and this is passed to this routine
>>
>> int FileStream::Read(void *pBuffer, int NBytes, int Timeout)
>> {
>>    if(mOSFileHandle == -1) {THROW_EXCEPTION(CommonException, 
>> FileClosed)}
>>    int r = ::read(mOSFileHandle, pBuffer, NBytes);
>>    if(r == -1)
>>    {
>>        THROW_EXCEPTION(CommonException, OSFileReadError)
>>    }
>>    if(r == 0)
>>    {
>>        mIsEOF = true;
>>    }
>>      return r;
>> }
>>
>> BUT only 215 is returned. The clue is that there are 3 lines of text 
>> in the file and
>> I think the EOLs are not being counted. If I print out pBuffer all 
>> the data is there
>> inc the EOLs.
>>
>> gcc version is...
>> gcc --version
>> gcc (GCC) 3.3.5 (Bird Build 2005-11-17 03:47)
>>
>>
>> Dave Bamford.
>>
>>
>>
>>
>
>


--------------080008030204070608090801
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-15"
 http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffcc" text="#663366">
Its running on an OS2 platform, I am porting boxbackup, an online
backup program so the<br>
files must be read exactly (ie I want to preserve the CF LF pairs)<br>
AFAIK there are no workarounds needed on a linux platform or with the
win32 port<br>
(there may be but I can't find them).<br>
I have contacted the developer and he may help<br>
<br>
I have tried looking at the gcc source to find out if ::read should
strip CRLF to CR only<br>
but I can't find this out.<br>
<br>
Dave<br>
<br>
Jon Saxton wrote:
<blockquote cite="mid438BE8E0.4030200 at triton.vg" type="cite">Is this
code executing on a DOS, OS/2 or Windows platform?  If so then I'd say
CR-LF pairs are being translated to LF on input.
  <br>
  <br>
There are several workarounds.  One is to read the file in binary mode
as Dave Yeo suggests but you'll get the carriage returns in your data
which may not be what you want.  Another is to pre-strip carriage
returns from the file using any of several programs which exist for
that purpose.  A third option is to recognise the cause and ignore the
discrepancy.
  <br>
  <br>
  <br>
Dave Bamford wrote:
  <br>
  <br>
  <blockquote type="cite">I have got a problem with porting some code.
    <br>
It reads data from a file into memory, the filesize as reported by
"dir" is 218 bytes
    <br>
and this is passed to this routine
    <br>
    <br>
int FileStream::Read(void *pBuffer, int NBytes, int Timeout)
    <br>
{
    <br>
   if(mOSFileHandle == -1) {THROW_EXCEPTION(CommonException,
FileClosed)}
    <br>
   int r = ::read(mOSFileHandle, pBuffer, NBytes);
    <br>
   if(r == -1)
    <br>
   {
    <br>
       THROW_EXCEPTION(CommonException, OSFileReadError)
    <br>
   }
    <br>
   if(r == 0)
    <br>
   {
    <br>
       mIsEOF = true;
    <br>
   }
    <br>
     return r;
    <br>
}
    <br>
    <br>
BUT only 215 is returned. The clue is that there are 3 lines of text in
the file and
    <br>
I think the EOLs are not being counted. If I print out pBuffer all the
data is there
    <br>
inc the EOLs.
    <br>
    <br>
gcc version is...
    <br>
gcc --version
    <br>
gcc (GCC) 3.3.5 (Bird Build 2005-11-17 03:47)
    <br>
    <br>
    <br>
Dave Bamford.
    <br>
    <br>
    <br>
    <br>
    <br>
  </blockquote>
  <br>
  <br>
</blockquote>
<br>
</body>
</html>

--------------080008030204070608090801--


**= Email   5 ==========================**

Date:  Tue, 29 Nov 2005 08:40:33 +0000
From:  Dave Bamford <dave at logical-progress.com>
Subject:  Re:  strange behaviour with file read (solved)

Problem solved

As suggested in the Innotek forum I found the file was not open in BINARY
added O_BINARY to the open flags and Hey Presto....

Dave

Dave Bamford wrote:

> Its running on an OS2 platform, I am porting boxbackup, an online 
> backup program so the
> files must be read exactly (ie I want to preserve the CF LF pairs)
> AFAIK there are no workarounds needed on a linux platform or with the 
> win32 port
> (there may be but I can't find them).
> I have contacted the developer and he may help
>
> I have tried looking at the gcc source to find out if ::read should 
> strip CRLF to CR only
> but I can't find this out.
>
> Dave
>
> Jon Saxton wrote:
>
>> Is this code executing on a DOS, OS/2 or Windows platform?  If so 
>> then I'd say CR-LF pairs are being translated to LF on input.
>>
>> There are several workarounds.  One is to read the file in binary 
>> mode as Dave Yeo suggests but you'll get the carriage returns in your 
>> data which may not be what you want.  Another is to pre-strip 
>> carriage returns from the file using any of several programs which 
>> exist for that purpose.  A third option is to recognise the cause and 
>> ignore the discrepancy.
>>
>>
>> Dave Bamford wrote:
>>
>>> I have got a problem with porting some code.
>>> It reads data from a file into memory, the filesize as reported by 
>>> "dir" is 218 bytes
>>> and this is passed to this routine
>>>
>>> int FileStream::Read(void *pBuffer, int NBytes, int Timeout)
>>> {
>>>    if(mOSFileHandle == -1) {THROW_EXCEPTION(CommonException, 
>>> FileClosed)}
>>>    int r = ::read(mOSFileHandle, pBuffer, NBytes);
>>>    if(r == -1)
>>>    {
>>>        THROW_EXCEPTION(CommonException, OSFileReadError)
>>>    }
>>>    if(r == 0)
>>>    {
>>>        mIsEOF = true;
>>>    }
>>>      return r;
>>> }
>>>
>>> BUT only 215 is returned. The clue is that there are 3 lines of text 
>>> in the file and
>>> I think the EOLs are not being counted. If I print out pBuffer all 
>>> the data is there
>>> inc the EOLs.
>>>
>>> gcc version is...
>>> gcc --version
>>> gcc (GCC) 3.3.5 (Bird Build 2005-11-17 03:47)
>>>
>>>
>>> Dave Bamford.
>>>
>>>
>>>
>>>
>>
>>
>



**= Email   6 ==========================**

Date:  Tue, 29 Nov 2005 08:58:05 +0000 (GMT)
From:  "Dave Saville" <dave at deezee.org>
Subject:   OT apache .htaccess logs

Can anyone send/post an extract from an apache log showing .htaccess allowed
and denied?

TIA

-- 
Regards

Dave Saville



**= Email   7 ==========================**

Date:  Tue, 29 Nov 2005 09:58:13 +0100
From:  "Stefan.Neis at t-online.de" <Stefan.Neis at t-online.de>
Subject:  Re:  strange behaviour with file read

         Hi,
>  Its running on an OS2 platform, I am porting boxbackup, an
>  online backup program so the files must be read exactly

Then you do want to open the files in binary mode
(e.g. use fopen(..., "rb") instead of fopen(..., "r"), or -
as Dave pointed out - by using -Zbin-files).

>  AFAIK there are no workarounds needed on a linux platform

Yes, unix platforms use a simple "LF" for line break in text files,
not the insane "CRLF" combination used by (Win)DOS and OS/2.

>  or with the win32 port (there may be but I can't find them).

That would be really surprising. 

> I have tried looking at the gcc source to find out if ::read should
> strip CRLF to CR only but I can't find this out.

Actually, to "LF" only, IIRC. You'd need to look at the source-code
for "read", it's standard behaviour for the C functions on the DOSish
(wrt linebreaks) platforms. 

        Regards,
                Stefan




**= Email   8 ==========================**

Date:  Tue, 29 Nov 2005 20:35:40 +1100 (EDT)
From:  "IanM" <IanM>
Subject:  Re:  OT apache .htaccess logs

Hi Dave

>Can anyone send/post an extract from an apache log showing .htaccess allowed
>and denied?

========== httpd.conf bits =======

LoadModule access_module      libexec/access.dll
LoadModule auth_module           	libexec/auth.dll
AccessFileName .htaccess
<Files .htaccess>
deny from all
</Files>
<Files ~ "^\.ht">
    Order Deny,Allow
    Deny from all
</Files>
#<big snip from file :>
# the following bit contains what uses .htaccess
NameVirtualHost 192.168.1.2:80
<VirtualHost 192.168.1.2:80>
    ServerName another.com.au
    DocumentRoot x:/another
     RewriteEngine On
     RewriteOptions inherit
     CustomLog logs/another.log combined
    <Directory "X:/another/members">
         Options ExecCGI
         AllowOverride AuthConfig
         Order allow,deny
         Allow from all
         AuthType Basic
    </Directory>
</VirtualHost>

========== httpd.conf bits end =======

========== .htaccess ==========
AuthUserFile x:/another/members/.htarsed

AuthGroupFile nul
AuthName "Members Area"
AuthType Basic

<Limit GET POST>
require valid-user
</Limit>
========== .htaccess end ==========


============= another.log (allowed) ============
57.84.82.81 - user12 [28/Nov/2005:20:33:41 +1100] "GET /members/index.html HTTP/1.1" 304 - "http://www.another.com.au/index.html" "Mozilla/4.0 (compatible; MSIE 6.0; Windows 
NT 5.1; SV1; .NET CLR 1.1.4322)"
57.84.82.81 - user12 [28/Nov/2005:20:35:32 +1100] "GET /members/photos.html HTTP/1.1" 304 - "http://www.another.com.au/members/index.html" "Mozilla/4.0 (compatible; MSIE 
6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)"
============= another.log end ============

note that after the IP address, instead of two blanks (represented as - ), there
is only one - then the username.

============= another.log (NOT allowed) ============
192.168.1.99 - - [29/Nov/2005:20:29:00 +1100] "GET /members/index.html HTTP/1.1" 401 409 "http://www.another.com.au/members.html" "Mozilla/5.0 (AIX; U; 4.3.3; 
en-US; rv:1.9.a2) Gecko/20051128 SeaMonkey/1.9a"
192.168.1.99 - "" [29/Nov/2005:20:29:04 +1100] "GET /members/index.html HTTP/1.1" 401 409 "http://www.another.com.au/members.html" "Mozilla/5.0 (AIX; U; 
4.3.3; en-US; rv:1.9.a2) Gecko/20051128 SeaMonkey/1.9a"
192.168.1.99 - trying [29/Nov/2005:20:29:19 +1100] "GET /members/index.html HTTP/1.1" 401 409 "http://www.another.com.au/members.html" "Mozilla/5.0 (AIX; U; 
4.3.3; en-US; rv:1.9.a2) Gecko/20051128 SeaMonkey/1.9a"
============= another.log end ============

first entry above is when the popup box showed.
note that a blank username entry simply gives "", I then entered trying as the username :-)


Cheers
IanM
http://www.os2site.com/

"A man flattened by an opponent can get up again.  A man flattened by conformity stays down for good." (T.Watson Jr)


**= Email   9 ==========================**

Date:  Tue, 29 Nov 2005 20:41:21 +1100 (EDT)
From:  "IanM" <IanM>
Subject:  Re:  OT apache .htaccess logs

Oops, forgot to paste this bit....

========= Error.log start ===========
[Tue Nov 29 20:29:04 2005] [error] [client 192.168.1.99] user  not found: /members/index.html
[Tue Nov 29 20:29:04 2005] [error] [client 192.168.1.99] user  not found: /members/index.html
[Tue Nov 29 20:29:19 2005] [error] [client 192.168.1.99] user trying not found: /members/index.html
[Tue Nov 29 20:29:19 2005] [error] [client 192.168.1.99] user trying not found: /members/index.html
========= Error.log end ===========

Cheers
IanM
http://www.os2site.com/

If you haven't much education you must use your brain.