FileRead throws error with *unix style text file and returns no chars.

I'm editing an install of ClamAV. Its configuration is stored in a clamav.conf file which is in unix format. i.e. Only char(10) endings. $\n no $\r$\n's.

ReadFile throws error and quits.
ReadFileBytes throws error and quits.

Is there a macro I can edit that will patch this behavior?

Yes. I've wrapped it in a ifFileExists test. The path is correct.
The call is:

  

ifFileExists "$INSTDIR/conf/clamd.conf" 0 errorNoConfFile  ; if this doesn't exist there is a problem....



       !insertmacro ReplaceInFile "$INSTDIR/conf/clamd.conf" "MailFollowURLs Yes" "MailFollowURLs No"

       ClearErrors

  errorNoConfFile:

Fails.
The ReplaceInFile macro kicks out at FileRead $R0 $R3, which is the first file read line in the macro. I've attempted to modify with FileReadBytes I still can't get data to return from the read. HELP!

I have attached a copy of the file to ask if anyone else can open and successfully read lines from this file. I've had to change the file name to end in .txt for upload.
Thanks.

can you read just the first line? perhaps it's trying to read the wrong line (say, past the end of the file or so)?

	FileOpen $0 "c:\temp\clamd.conf" "r"

	FileRead $0 $1

	MessageBox MB_OK "[$1]"

	FileClose $0

Gives...

---------------------------

Test Setup

---------------------------

[##

]

---------------------------

OK   

---------------------------

Using your same code, I got no error... verified that the file is still using only 0A, not 0A0D, and 'MailFollowUrls No' is followed by 0A0A

StepThough.....

Ok, well I confirmed your test. I can acutally open the file seperately, and rip through it. I get all teh ## lines etc. So then I edited the ReplaceInFile's central function called RIP... as you see...I have inserted an output test of the initial parameters, and alerts if any of the preceeding items throw errors. This should enter into its search and hit us with 1000 annoying message boxes as it rips through each line in the file.... however... that doesn't happen. We exit with the first alert, and dump to close because of the errors being set.



What determines the EOF for the FileRead function?

Is there ANY other reason that FileRead would return with the error flag set other than reaching the end of file? Its returning both Empty and Errors set.... indicating the end of file...

But if we manually open the file and read a line we get one.... is there something about being in the macro???

Function RIF



  ClearErrors  ; want to be a newborn



  Exch $0      ; REPLACEMENT

  Exch

  Exch $1      ; SEARCH_TEXT

  Exch 2

  Exch $2      ; SOURCE_FILE



  Push $R0     ; SOURCE_FILE file handle

  Push $R1     ; temporary file handle

  Push $R2     ; unique temporary file name

  Push $R3     ; a line to sar/save

  Push $R4     ; shift puffer

  Push $R5     ; byteHolder

  Push $R6     ; buffer counter

  MessageBox MB_OK "Data before open read. $0 , $1 , $2"

  IfFileExists $2 +1 RIF_error      ; knock-knock

  ifErrors 0 +2

    MessageBox MB_OK "Errors existed before open read. $0 , $1 , $2"

    ClearErrors

  FileOpen $R0 $2 "r"               ; open the door

  ifErrors 0 +2

    MessageBox MB_OK "Errors existed after open read. $2"

    ClearErrors

  GetTempFileName $R2               ; who's new?

  FileOpen $R1 $R2 "w"              ; the escape, please!

  ifErrors 0 +2

    MessageBox MB_OK "Errors existed after open write $2"

    ClearErrors

  RIF_loop:                         ; round'n'round we go

    FileRead $R0 $R3                ; read one line

        MessageBox MB_OK "$R3"



    ifErrors RIF_leaveLoop



    RIF_sar:                        ; sar - search and replace

      Push "$R3"                    ; (hair)stack

      Push "$1"                     ; needle

      Push "$0"                     ; blood

      Call StrReplace               ; do the bartwalk

      StrCpy $R4 "$R3"              ; remember previous state

      Pop $R3                       ; gimme s.th. back in return!

      StrCmp "$R3" "$R4" +1 RIF_sar ; loop, might change again!

    FileWrite $R1 "$R3"             ; save the newbie

  Goto RIF_loop                     ; gimme more



  RIF_leaveloop:                    ; over'n'out, Sir!



    FileClose $R1                   ; S'rry, Ma'am - clos'n now

    FileClose $R0                   ; me 2

    ;MessageBox MB_OK "Files Closed. $R1 , $R0"

    Delete "$2.old"                 ; go away, Sire

    ;MessageBox MB_OK "Deleete $2.old"

    Rename "$2" "$2.old"            ; step aside, Ma'am

    ;MessageBox MB_OK "Rename $2 to $2.old"

    Rename "$R2" "$2"               ; hi, baby!

    ;MessageBox MB_OK "Rename $R2 to $2"

    Delete "$2.old"

    ClearErrors                     ; now i AM a newborn

    Goto RIF_out                    ; out'n'away



  RIF_error:                        ; ups - s.th. went wrong...

    SetErrors                       ; ...so cry, boy!



  RIF_out:                          ; your wardrobe?

  Pop $R6

  Pop $R5

  Pop $R4

  Pop $R3

  Pop $R2

  Pop $R1

  Pop $R0

  Pop $2

  Pop $0

  Pop $1



FunctionEnd

well that's the odd thing - even with your new RIF Function with the debug messageboxes - it continues to work just fine. I get a ton of messageboxes and the end result is that in "c:\temp\clamd.conf" (the filename I'm passing), the line "MailFollowURLs Yes" is replaced with "MailFollowURLs No".

Are you saying that it throws up this error..

  ifErrors 0 +2

    MessageBox MB_OK "Errors existed before open read. $0 , $1 , $2"

..?
If so, perhaps include more ClearError / IfErrors -> MessageBox debug points to figure out where on earth it thinks it's erroring. The only time I get that error is if the file does not, in fact, exist at "c:\temp\clamd.conf"

Stupid stupid stupid stupid.
Using forward slashes in file name creates impossible read errors.

Every read after that results in error flag being set. However, NO error flag on FileOpen????? VERY STRANGE.

Thanks for helping me push this to conclusion. I was ( by requirment for ClamAV ) using forward slashed paths because ClamAV needs/expects them in its *nix config file formats. So... my convention read C:/Program Files/clamAV/conf/clamd.conf

Why this doesn't create throws on FileOpen is beyond me.

But converting to C:\\Program Files\clamAV\conf\clamd.conf creates success with the read calls.

???Bug??? FileOpen should throw this error before read consistantly...

And ifFileExists should return an error if that is not a supported path definition.... but ifFileExists would pass the test too!