Wed 20 Feb 2008 04:37:00 PM UTC, comment #11:
Yep, fixed.
|
Wed 13 Feb 2008 02:03:46 PM UTC, comment #10:
It does create the SOL now.
Not-recognition as a SOL afterwards is back now,
soldumper kind of recognizes it still..
Anway, the original bug is fixed for me, I suggest
we open others for other problems.
|
Wed 13 Feb 2008 01:38:16 PM UTC, comment #9:
Alright, I was wrong, SharedObject checks the wrong path
(the one w/out slashes in it) and thus doesn't create
any intermediate directory, while sol.cpp is asked
to write the file with full path, which isn't available..
Committed more error handling that makes this clear.
|
Wed 13 Feb 2008 12:50:04 PM UTC, comment #8:
ok, first thing to note is that a so.data member must be set to
expect it to be saved.
Beside that, it seems the "filespec" associated with
the SharedObject doesn't contain the full path as printed
by the SECURITY message but just the last component.
Still, the file is not written.
THe code doesn't check return code from amf::writeFile either,
which may help..
|
Sun 10 Feb 2008 12:42:32 PM UTC, comment #7:
There are a few separate issues here;
- The message "SECURITY: empty SOL file, file.sol created." does not accurately reflect what the code does. In reality, the SOL file will not be created /until/ SharedObject.flush() is called.
- Apparently, in strk's testcase, flush() does not succeed in creating the requested SOL file.
- According to docs, if flush() is never called, then Gnash should write out the SOL file at SWF "shutdown". As far as I can tell, our SharedObject doesn't do this.
|
Thu 07 Feb 2008 02:01:51 PM UTC, comment #6:
NOTE: the test file in comment #5 gives this message:
SECURITY: Opening SharedObject file: /home/strk/.gnash/SharedObjects/localhost//home/strk/src/gnash/build/head/allgui_agg_gst_debugging/testSharedObj.swf/bug22013.sol
SECURITY: empty SOL file, "/home/strk/.gnash/SharedObjects/localhost//home/strk/src/gnash/build/head/allgui_agg_gst_debugging/testSharedObj.swf/bug22013.sol", created
But then, the file is not there...
|
Tue 22 Jan 2008 08:30:49 AM UTC, comment #5:
Here's a simple code to verify that the message states the file would be created while you don't find it there afterwards:
so = SharedObject.getLocal("bug22013");
so.flush();
|
Tue 22 Jan 2008 08:28:33 AM UTC, comment #4:
Mmm.. the error message is gone for me too, but
a close look shows that the SOL file is not created
at all, despite the SECURITY message says so:
17022] 09:28:55: SECURITY: Opening SharedObject file: /home/strk/.gnash/SharedObjects/soundData.sol
17022] 09:28:55: SECURITY: empty SOL file, "/home/strk/.gnash/SharedObjects/soundData.sol", created
17022] 09:28:56: SECURITY: Opening SharedObject file: /home/strk/.gnash/SharedObjects/videostats.sol
17022] 09:28:56: SECURITY: empty SOL file, "/home/strk/.gnash/SharedObjects/videostats.sol", created
After that, you quit and ls shows there's no such .sol.
You need to remove the pre-existing .sol files to reproduce.
|
Tue 22 Jan 2008 08:06:44 AM UTC, comment #3:
Works for me now.
|
Tue 22 Jan 2008 01:26:56 AM UTC, comment #2:
sigh, swap host to network, not the other way around when writing a file.
|
Sun 13 Jan 2008 04:47:47 PM UTC, comment #1:
I also belive the problem is in writing.
If you copy an "official" .sol file there you should
have no problems.
I got confused too intially, and "fixed" the reader,
till I realized the reader was right.
|
Sun 13 Jan 2008 03:09:46 PM UTC, original submission:
I get "ERROR: /home/benjamin/.gnash//videostats.sol isn't an SOL file" when Gnash tries to open SOL files that it created. The check looks for 0x00BF at the beginning of the file, my files start with 0xBF00.
From the wiki (http://wiki.gnashdev.org/wiki/index.php/SOL) and the comment on line 58 of sol.cpp I'd guess the check is right and the files are getting written incorrectly on little-endian machines.
|