Wiz troubles writing to binary file

[Darmakwolf]

Can someone possibly help me determine if this is a bug? Basically this program I have made lets the user select a NES rom file, it copies the rom to a new location, opens the file, writes a few bytes, closes the rom. On Windows, this works all well and good. On the GP2X-Wiz, everything APPEARS to work fine. All of the files are there, it can confirm the existence of the files, it successfully copies the files to the new location... but cannot alter them. Is there an issue with FILESEEK and WRITEUBYTE? Like I said above, in Windows, the bytes are written to the correct places and the rom is edited succesfully. With debugging information on the GP2X-Wiz I can see that it can find the rom perfectly fine, but writing bytes does nothing to the file on the Wiz. Windows has no issue. Anything I'm overlooking?

the writing portion basically looks like this:

LOCAL ok = OPENFILE(1,"copy_" + srom$,-1)
LOCAL pix = romaddr
FILESEEK 1,pix,0
WRITEUBYTE 1,number
CLOSEFILE 1

[Moru]

Sorry, couldn't keep myself from changing that title to something useful :-)

Wiz is running linux so check the rights and where that file is located. It might be problems writing to it because your application doesn't have the correct rights to write.

[Darmakwolf]

Okay thanks - but how would I go about doing that?

[Kitty Hello]

try LOCAL pix% (use an integer)
also, try a binary compare of the files generated on win and wiz.
the OK value from openfile is true?

[hardyx]

Okay thanks - but how would I go about doing that?

If the original files are write protected, then the destination files can be the same attribute enabled. You can see the attributes using the command "ls -l" in the Linux terminal (Termula on wiz). Launch Termula and use the command "ls -l /mnt/sd/folder/yourfile.nes" to see the attributes. Change the part "folder/yourfile.nes" for the current path to your file. If you see the "r" letter in the result line the file is read-only.

[Darmakwolf]

Honestly is there a way to force it to have a writable attribute? Obviously in Windows it is read/write. I just read the log from my debugger and it successfully found the file, successfully copied the file to a new location, and openfile reports that the file is there. The actual writing still does not occur. Is there a shellcmd that forces it to be writeable? This is kind of frustrating.

[Darmakwolf]

Termula reports -rwxr-xr-x

[Darmakwolf]

I think writing to files that already exist on the GP2X-Wiz with WRITEUBYTE or similar functions is faulty. I could be completely wrong, but the file is there, writable, and glbasic reports that it is there and writable. Can someone with a WIZ please make a simple program that writes bytes to positions in a file to see? The "altered" file is always a binary duplicate of the copied file - nothing is changed. argh!

[hardyx]

Termula reports -rwxr-xr-x

In this case, the first "rw" means that you can read and write the file.

In the first post you use OPENFILE with mode -1 (append). This mode moves the write pointer to the end of the file. Use the mode 0 (write), and test if this works.

[Darmakwolf]

The problem here is that this erases the entire contents of the file and only puts values where I specify, reducing the file size to 1 KB because it blanks all the other data. Append works perfectly on windows for replacing values )=

[Darmakwolf]

So if I turn on debug injection - every time it gets to writebyte or any writing function it returns "no file" .... obviously there's a file..... maybe it's an issue with forward-slash directories and backward slash? (just a wild guess)  I've tried setcurrentdir millions of ways.

[MrTAToad]

It could be that the file position has exceeded the length of the file, or as it says, the file cant be written...

Shouldn't you use 0 as the third parameter with OPENFILE ?

[Kitty Hello]

try something simple:

Code (glbasic) Select Expand


LOCAL file$ = "Media/test.txt"
OPENFILE 1, file$, 0
WRITELINE 1, "test 1"
CLOSEFILE 1

OPENFILE 1, file$, -1 // append
WRITELINE "test 2"
CLOSEFILE 1


And then check the contents of this file. Use a filename in your directory for file$.