Opened 6 years ago

Closed 6 years ago

Last modified 6 years ago

#60 closed defect (fixed)

Flash 10.1 and above can't create folders and files for settings/cache

Reported by: dmik Owned by:
Priority: major Milestone: 0.4.0
Component: wrapper Version:
Severity: high Keywords:


Flash should store local security settings and shared objects in the \var\lib\odin\Application Data\Macromedia Flash Player directory. If it is unable to store or read the contents of this directory (and its subdirectories), it will cause error #2060 (and sometimes the subsequent error #2134).

On Windows, this directory (and all necessary subdirectories) gets re-created by the Flash plugin as needed. Shared objects are stored in a subdirectory #SharedObjects?\NNNNNNNN\, security settings -- in\somestuff\

On OS/2, Flash versions starting from 10.1 do not create any directories there at all (I don't even see a call to CreateDirectory?? in Odin logs). Flash 10.0.x creates the directory structure but it is still unable to create NNNNNNNN in #SharedObjects?? (where N is a digit or a capital letter). If I create the NNNNNNNN directory by hand (or transfer the whole Flash Player structure from the Windows machine), Flash 10.0.x starts working fine with the IKEA movie (and it stores some stuff in there). Flash 10.1 and above still doesn't work.

As far as I can judge from the logs, they changed something in Flash regarding to the code that creates the directory structure and walks it, as the sequence of API calls is completely different starting from version 10.1. There is not enough information to figure out what's wrong though. Most likely, we don't implement some functionality but nothing in the logs suggests what exactly is missing.

Note that Flash 10.0 and the manually created directory only cure the IKEA site. The mouse clicks (​ticket:34) and embedded videos (ticket:57) still don't work. Must be something different. Bad that the debug version of Flash shows nothing in these cases.

Change History (17)

comment:1 Changed 6 years ago by dmik

  • Summary changed from Flash 10.3 and above can't create folders and files for settings/cache to Flash 10.1 and above can't create folders and files for settings/cache

comment:2 Changed 6 years ago by dmik

JFYI, contains a lot of related information.

comment:3 Changed 6 years ago by dmik

Since we don't have Flash sources, I see two ways to debug this problem:

  1. Use Win32 API sniffer on a real Win32 machine to see what APIs Flash calls there and when (in order to create folders and files with objects/settings). Disassembling Flash may also be required.
  1. Find out an ActionScript? 3.0 test case that reveals the problem. Doing step 1 may still be necessary.

This (especially step 1) is not something fast and easy, so I think it may take some time.

If nobody minds, I suggest to postpone this defect in favor of other ones.

comment:4 Changed 6 years ago by dmik

There is also a 3rd option to obtain the sources of some Flash movie that doesn't work and play with them.

comment:6 Changed 6 years ago by diver

some more infos eventually

comment:7 Changed 6 years ago by diver

  • Severity set to high

comment:8 Changed 6 years ago by dmik

The problem with the inability to create directories becomes clear now. There is a whole bunch of incorrect code in Odin in the Handle Manager. The root of the problem is the misinterpretation of the result. For example, the GetFileInformationByHandle?() API returns BOOL (success indicator), however the virtual call HMDeviceHandler::GetFileInformationByHandle?() which is used to implement this API (through overriding in subclasses) returns DWORD and, more over, it's default implementation returns ERROR_INVALID_FUNCTION.

ERROR_INVALID_FUNCTION is 1 so when this virtual is called from GetFileInformationByHandle?() the application interprets it as BOOL and gets TRUE. TRUE means the API has succeeded while it is in fact not. This made Flash think the directories it tries to create exist and not create them. Temporary hacking it so that it returns 0 (FALSE) instead fixes the problem.

There are more invalid APIs like that and they need to be checked too. Probably inability to create files lies in this area too. Will check this tomorrow.

comment:9 Changed 6 years ago by jojo

Hi Dmitriy,

good job hunting this down, gives me hope that we can finally tackle this!


comment:10 Changed 6 years ago by abwillis

Can we use do something like:

return O32_GetFileInformationByHandle(pHMHandleData->hHMHandle,


GetFileInformationByHandle? is implemented in hmopen32.cpp with the above.
It at least seems to work, from what I can see anyhow so far, at least global settings are sticking now.

comment:11 Changed 6 years ago by abwillis

With this setting I am creating not only the folder structure but also the .sol files.

comment:12 Changed 6 years ago by dmik

Well, the dummy implementation (in HandlerDevice?) *must* return FALSE as it's dummy. The fact that O32_GetFileInformationByHandle() works for dirs is a good finding but it should be brought to the game in a different way -- by properly instantiating objects of HMDeviceOpen32Class() for directories (instead of the dummy HMDeviceHandler). I will check that next.

I'm having problems with the release version of the plugin, it crashes somewhere in the Win32 DLL and doesn't create directories still. This may be related to the above.

comment:13 Changed 6 years ago by abwillis

I had tried to figure out how to do it the right way but I don't understand C++ enough to have figured out how it was calling HandlerDevice? to determine how to point it instead to the HMDeviceOpen32Class. Finally I just stuck it over to see if it was even worth bothering and it seems to work out. I also was wondering if something similar needed to be added for CreateFile? but then I found that the sol files at least were being created.
No crashes here with the release version...

comment:14 Changed 6 years ago by dmik

My crashes seem to deal with SECURIT2.DLL somehow. Needs investigation too -(

comment:15 Changed 6 years ago by diver

i built latest odin and didn't see crashes so far. a lot more flash play now

comment:16 Changed 6 years ago by dmik

No, it was not SECURIT2.DLL. It was the old Odin DLLs that somehow slipped in.

Regarding O32_GetFileInformationByHandle(). I checked it again and it doesn't make sense to call it from there at all, more over, it's just simply not correct. It worked for you just by accident since it also fails and returns FALSE.

While studying the HMDevice herarchy I found that Open32 file APIs are not used in the current Odin at all. Instead, Odin substitutes all places where HMDeviceOpen32Class is about to be used with HMDeviceFileClass / HMDeviceInfoFileClass (OS/2 File APIs). Perhaps this is done to make the underlying file handles usable outside Odin (as they are normal OS/2 file handles in this case).

I don't know if Open32 APIs can open directories or not, but in Odin this is implemented with HMDeviceInfoFileClass which doesn't actually open the given file name but is simply able to provide meta information about the path by querying the respective OS/2 APIs. It just misses the implementation of the GetFileInformationByHandle?() virtual call which I will now implement to close this issue.

So, instead of always returning FALSE on directories opened with CreateFile?() (as my intermediate fix currently does), we will return TRUE and some useful information about them.

comment:17 Changed 6 years ago by dmik

  • Resolution set to fixed
  • Status changed from new to closed

GetFileInformationByHandle?() for directories is fixed in Odin r22026.

As cache directories and files seem to be successfully created now, this defect may be considered as done. Note that Flash settings (.sol files) also work now which means changes are preserved between sessions.

Last edited 6 years ago by dmik (previous) (diff)
Note: See TracTickets for help on using tickets.