http://bugs.winehq.org/show_bug.cgi?id=23115
Summary: IStorage Created with StgOpenStorageOnILockBytes doesn't use 'Stat' method of the IlockBytes Object Product: Wine Version: 1.1.39 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: ole32 AssignedTo: wine-bugs@winehq.org ReportedBy: rawlik@list.ru
IStorage objects created with StgOpenStorageOnILockBytes function doesn't use the 'Stat' method of the 'IlockBytes' Object for detect real path of the Compound file. Some programs that use this path can't open internal streams of the compund files.
http://bugs.winehq.org/show_bug.cgi?id=23115
--- Comment #1 from Dmitry Timoshkov dmitry@codeweavers.com 2010-06-11 04:59:05 --- What application is affected by this? Can you add a test case? Retesting with 1.2-rc2 would be useful as well.
http://bugs.winehq.org/show_bug.cgi?id=23115
--- Comment #2 from Pavel rawlik@list.ru 2010-06-11 05:25:03 --- (In reply to comment #1)
What application is affected by this?
1Cv7*.exe
http://bugs.winehq.org/show_bug.cgi?id=23115
--- Comment #3 from Pavel rawlik@list.ru 2010-06-11 08:44:35 --- Created an attachment (id=28730) --> (http://bugs.winehq.org/attachment.cgi?id=28730) My variant of solution (not the best :-)
Copy the filename field from IlockBytes object to IStorage.
http://bugs.winehq.org/show_bug.cgi?id=23115
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch
http://bugs.winehq.org/show_bug.cgi?id=23115
--- Comment #4 from Nikolay Sivov bunglehead@gmail.com 2010-06-11 15:17:11 --- Pavel, could you produce a minimal test case program that shows this problem? It's even better to add it as to Wine tests in ole32/tests.
http://bugs.winehq.org/show_bug.cgi?id=23115
--- Comment #5 from Pavel rawlik@list.ru 2010-06-14 06:38:03 --- (In reply to comment #4)
Pavel, could you produce a minimal test case program that shows this problem? It's even better to add it as to Wine tests in ole32/tests.
(In reply to comment #4)
Pavel, could you produce a minimal test case program that shows this problem? It's even better to add it as to Wine tests in ole32/tests.
Test case require a IlockBytes File-based implementation as described on: http://msdn.microsoft.com/en-us/library/aa379238%28v=VS.85%29.aspx
* File-based implementation
If you call StgCreateDocfile function to create a compound file storage object, it contains an implementation of ILockBytes that is associated with a byte array stored in a physical disk file. The compound file storage object calls the ILockBytes methods — you do not call them directly in this implementation.
It's not so easy to do quickly :-).
Good.
I'l try to write MINIMAL test case soon.
http://bugs.winehq.org/show_bug.cgi?id=23115
--- Comment #6 from Vincent Povirk madewokherd@gmail.com 2010-06-14 09:17:52 --- There don't seem to be many ways to access the standard file-based implementation. So far I've only found StgGetIFillLockBytesOnFile, which is still a stub in the spec.
For your test, you could use any implementation of ILockBytes whose Stat method behaves the way you want.
The patch no longer applies to current Wine. The Stat implementation is now shared between the different types of storage objects. I guess we need an internal method for getting the filename (if applicable) that depends on the particular storage implementation.
http://bugs.winehq.org/show_bug.cgi?id=23115
--- Comment #7 from Pavel rawlik@list.ru 2010-06-15 02:48:08 --- The program mentioned above 1Cv7.exe realizes it's own Object with 'IlockBytes' interface (but I haven't the source code).
i.e. The test case needs to realize it's own Object with 'IlockBytes' interface too, with Stat method that returns the Filename field.
And the native behavior of IStorage::Stat seems to call the 'Stat' method of the 'Parent' storage (IStream,IlockBytes, e.t.c.)
http://bugs.winehq.org/show_bug.cgi?id=23115
--- Comment #8 from Nikolay Sivov bunglehead@gmail.com 2010-06-15 02:58:21 --- So it's simple to test. You need a stub ILockBytes implementation in test, that returns some path with ::Stat(), and then a check to IStorage::Stat() that returns the same path. Also it's nice to have a simple check to know that ILockBytes::Stat() called every time IStorage::Stat() called, so no internal caching or something like that happens.
http://bugs.winehq.org/show_bug.cgi?id=23115
--- Comment #9 from Pavel rawlik@list.ru 2010-06-16 09:28:06 --- Created an attachment (id=28886) --> (http://bugs.winehq.org/attachment.cgi?id=28886) console test and, source and a comopund file
(copy/paste/clean surplus from memlockbyte.c) This test works fine under Windows but under wine not :D under Wine FileCreateW don't open the file if the path is multibyte.
Under Windows. My IlockBytes::Stat method it's called 3 times, But all 3 times without querying filename. And finally: The file name is returned correct ! ???????
http://bugs.winehq.org/show_bug.cgi?id=23115
--- Comment #10 from Vincent Povirk madewokherd@gmail.com 2010-06-16 13:49:51 --- You created two storage objects, one from filename and one from ILockBytes, then stated the first one twice.
http://bugs.winehq.org/show_bug.cgi?id=23115
--- Comment #11 from Pavel rawlik@list.ru 2010-06-16 14:31:02 --- Created an attachment (id=28894) --> (http://bugs.winehq.org/attachment.cgi?id=28894) More correct test.
Sorry. I was too hasty.
Under Windows works as expected. IStorage:: Stat invokes IlockBytes:: Stat method.
http://bugs.winehq.org/show_bug.cgi?id=23115
--- Comment #12 from Pavel rawlik@list.ru 2010-06-22 08:42:12 --- (In reply to comment #6) ...
The Stat implementation is now shared between the different types of storage objects. I guess we need an internal method for getting the filename (if applicable) that depends on the particular storage implementation.
Maybe add a BIGBLOCKFILE_Stat method, and use them ? Because only this class (BIGBLOCKFILE) have direct access to the file handle and ILockBytes object.
http://bugs.winehq.org/show_bug.cgi?id=23115
--- Comment #13 from Vincent Povirk madewokherd@gmail.com 2010-06-23 17:14:32 --- Probably we should get rid of BigBlockFile and use an ILockBytes in all cases.
http://bugs.winehq.org/show_bug.cgi?id=23115
--- Comment #14 from Pavel rawlik@list.ru 2010-06-24 04:09:16 --- For compound files that size is comparable with RAM of the PC (i.e. 128 mb and more, my first PC had only 16Mb :-) ) * or IlockBytes code should be more smart (for example using mmap) * or use BigBlockFile instead.
http://bugs.winehq.org/show_bug.cgi?id=23115
--- Comment #15 from Vincent Povirk madewokherd@gmail.com 2010-06-24 09:08:47 --- Obviously, we'd need a new ILockBytes implementation that works based on a file.
http://bugs.winehq.org/show_bug.cgi?id=23115
--- Comment #16 from Vincent Povirk madewokherd@gmail.com 2010-07-17 14:15:14 --- Patch sent: http://www.winehq.org/pipermail/wine-patches/2010-July/090598.html
http://bugs.winehq.org/show_bug.cgi?id=23115
Pavel rawlik@list.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #28886|0 |1 is obsolete| |
http://bugs.winehq.org/show_bug.cgi?id=23115
--- Comment #17 from Austin English austinenglish@gmail.com 2010-07-19 15:05:21 --- (In reply to comment #16)
Patch sent: http://www.winehq.org/pipermail/wine-patches/2010-July/090598.html
Committed: http://source.winehq.org/git/wine.git/?a=commitdiff;h=d0e6e4aa828a73866bc730...
Please retest.
http://bugs.winehq.org/show_bug.cgi?id=23115
Pavel rawlik@list.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |FIXED
--- Comment #18 from Pavel rawlik@list.ru 2010-07-20 10:48:40 --- Thank you. Good job. It works.
http://bugs.winehq.org/show_bug.cgi?id=23115
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #19 from Alexandre Julliard julliard@winehq.org 2010-07-30 12:58:04 --- Closing bugs fixed in 1.3.0.