filewrite() not working in mode 16(BinaryMode).

[mvgulik]

; filewrite() not working in mode 16(BinaryMode).
; Environment = 3.3.1.1 under  WIN_XP/Service Pack 3 X86

Local $hFile,$filename = 'test.tmp'

$hFile=FileOpen($file,2) ; write,erase.
FileWrite($hFile,'abcdef' ) ; 0x61..0x66
FileClose($hFile)

$hFile=FileOpen($filename,16)
If ($hFile < 1) Then
	MsgBox(0,'error','[1] file not found.')
	Exit
EndIf

FileSetPos($hFile,2,0)
FileWrite($hFile,'CD')
;~ FileWrite($hFile,StringToBinary('CD'))
FileFlush($hFile)

FileSetPos($hFile,0,0)
MsgBox(0,'fileRead', BinaryToString(FileRead($hFile, 6)) )

FileClose($hFile)
Exit

[Jpm]

What's wrong that's working no error message, just the same string displayed
You open the file in read mode so filewrite fails.

I can agree that something can be wrong as opening with 16+1 or 1 just write at the end not at FileSetPos()
I don't know if FileSetPos() was only designed to position for FileRead()

[Valik]

FileSetPos() works correctly. The problem is not there. I see some strange stuff from our file functions, I suspect something is fundamentally broken with our implementation of FileOpen() although I have no clue what it could be. Definitely something is up, though. I'll take a look at it whenever I find time to revisit the file functions.

[mvgulik]

I wronly figured that with FileOpen-Binary support and the newly added fileSetPos it was posible to edit existing files directly in binary mode.

I'll put that into a request ticket.

[Valik]

Just to make sure you see the stuff I said in #1071 I'm making sure to link it here and reiterating somewhat.

What the fuck are you thinking? I just said there was a bug that I would look at. I didn't close this ticket. I said that FileSetPos() was working correctly but the bug was not there. So why the fuck would you go and create a new ticket asking for functionality in FileSetPos() when I said it was working? Here's a suggestion: When I write something, read it. It'll save you a whole lot of headaches and flaming if you just listen to me and not somebody who doesn't know what the fuck he's talking about.

[mvgulik]

Funny, I can't see any problem with FileSetPos either. Other than having used that word again in ticket #1071 to state something that to me seems like a obvious intended behavior related to the fileOpen-append mode.

O well. lets try something else.
Can I ask what it is you think that I reported in this report ticket.
and what it is you think that I requested in ticket #1071.

[Valik]

Jesus fucking Christ you're being stupid. I said the FileSetPos() function was not broke because its not. I said there is a bug somewhere else in our FileOpen() code. So let's think about that for three fucking seconds: Developer said there's a bug. Oh, maybe THERE'S A MOTHERFUCKING BUG IN THE CODE.

Do you get it now? Something is broke. That something is not FileSetPos(). But, something is broke none-the-less. So how about we wait until the bug is fixed before we go making stupid feature requests that make no sense anyway? Seriously, why would FileSetPos() not support a particular mode unless there was a bug somewhere (and that a developer acknowledged)?

I'm going to advise you to drop this now. A little bit of stopping and thinking would have saved you a hell of a lot of flaming. I don't take well to being flat out ignored and so the lesson you need to learn is when I say something don't ignore it.

[mvgulik]

Yea I get it now.
Thanks for clearing things up.

[Jpm]

FileOpen need to support a new mode Update which will allow read and write

[Valik]

Replying to Jpm:

FileOpen need to support a new mode Update which will allow read and write

No it doesn't. AutoIt always opens files in read mode even if they are open in write mode. That isn't the problem at all.

[Valik]

This is no longer blocking the release. To fix the problems requires a rewrite of the File functions which will not be done during this beta period.

[Valik]

Fixed by revision [5311] in version: 3.3.1.5

[Jpm]

This ticket is referenced in revision: [5316]