Modify

Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#1066 closed Bug (Fixed)

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

Reported by: mvgulik Owned by: Valik
Milestone: 3.3.1.5 Component: AutoIt
Version: 3.3.1.1 Severity: None
Keywords: filewrite binary Cc:

Description

; 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

Attachments (0)

Change History (13)

comment:1 Changed 10 years ago by 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()

comment:2 Changed 10 years ago by Valik

  • Owner set to Valik
  • Status changed from new to assigned

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.

comment:3 Changed 10 years ago by 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.

comment:4 Changed 10 years ago by 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.

comment:5 Changed 10 years ago by 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.

comment:6 Changed 10 years ago by 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.

comment:7 Changed 10 years ago by mvgulik

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

comment:8 follow-up: Changed 10 years ago by Jpm

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

comment:9 in reply to: ↑ 8 Changed 10 years ago by 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.

comment:10 Changed 10 years ago by Valik

  • Severity changed from None to Blocking

comment:11 Changed 10 years ago by Valik

  • Severity changed from Blocking to None

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.

comment:12 Changed 10 years ago by Valik

  • Milestone set to 3.3.1.5
  • Resolution set to Fixed
  • Status changed from assigned to closed

Fixed by revision [5311] in version: 3.3.1.5

comment:13 Changed 10 years ago by Jpm

This ticket is referenced in revision: [5316]

Guidelines for posting comments:

  • You cannot re-open a ticket but you may still leave a comment if you have additional information to add.
  • In-depth discussions should take place on the forum.

For more information see the full version of the ticket guidelines here.

Add Comment

Modify Ticket

Action
as closed The owner will remain Valik.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.