Grazvydas Ignotas notasas@gmail.com writes:
@@ -2004,6 +2004,8 @@ NTSTATUS WINAPI NtQueryDirectoryFile( HANDLE handle, HANDLE event, fstat( fd, &st ); curdir.dev = st.st_dev; curdir.ino = st.st_ino;
if (lseek( fd, 0, SEEK_CUR ) == 0)restart_scan = TRUE;
That won't work if we already returned '.' and '..'.
On Mon, Jul 18, 2011 at 1:41 PM, Alexandre Julliard julliard@winehq.org wrote:
Grazvydas Ignotas notasas@gmail.com writes:
@@ -2004,6 +2004,8 @@ NTSTATUS WINAPI NtQueryDirectoryFile( HANDLE handle, HANDLE event, fstat( fd, &st ); curdir.dev = st.st_dev; curdir.ino = st.st_ino;
- if (lseek( fd, 0, SEEK_CUR ) == 0)
- restart_scan = TRUE;
That won't work if we already returned '.' and '..'.
You mean fake '.' and '..'?
Do you have any suggestions how to track state between calls? I'm thinking about using global structure to track dev_t, ino_t and off_t (and maybe handle), and if any of those changes since last exit from the function consider it as a first call for this handle.
It looks like the best way would be to attach state to handle somehow (that would be dropped automatically on CloseHandle), but I failed to find a way to do so.
-- Alexandre Julliard julliard@winehq.org
Grazvydas Ignotas notasas@gmail.com writes:
You mean fake '.' and '..'?
Yes.
Do you have any suggestions how to track state between calls? I'm thinking about using global structure to track dev_t, ino_t and off_t (and maybe handle), and if any of those changes since last exit from the function consider it as a first call for this handle.
I don't think you can do that.
It looks like the best way would be to attach state to handle somehow (that would be dropped automatically on CloseHandle), but I failed to find a way to do so.
You can't do that either I'm afraid. It's a tricky problem.
Hi, As the subject says I am looking for some info about wine.
1) I am trying to understand how wine implements COM objects. I have read the wiki pages on COM and DCOM objects but I am interested in some further assistance.
Whats the easiest way to spot a function implementing part of an interface? Is there some kind of name scheme I can follow?
I can find the interface definitions easily enough in the header files or the idl files. I am having a little more trouble about the implementation.
About the IDL files: is every interface supposed to be defined in an IDL? Or only certain ones? And how would i know the difference? For instance I found the IQueryInfo interface which is only defined in an header file without any association to a CLSID nor does there seem to be an implementation.
2) I am trying to debug a deadlock of the x11 driver in Icewind Dale 1.
From the +relay,+opengl log it looks like one thread(#28) that deadlocks
calls SuspendThread with a HANDLE maybe to itself. #28 isn't suspended though and the only other thread(#9) running is interrupted within the x11 critical section doing an opengl call. When #28 wants to do an opengl call himself, it deadlocks. So maybe its #9 which is supposed to be suspended. Can it happen that the wine server suspends a thread in a critical section?
How can I get the thread id from that HANDLE? if i try to run with the +server debug channel enabled the problem will go away and my log output will be seriously garbled with half the chars at the beginning of a line missing sometimes.
Another problem will show up though that is when i run a debugger and do a bt the app seems to hang showing a message box. Unfortunately I am running in full screen mode in a virtual desktop and see no possibility to get to that message box. It seems to be hidden behind the full screen'd Icewind Dale. Is that a bug or working as intended?
Any ideas how I could debug this further?
Sorry for the Wall of Text(TM)
Thank you for your assistance
On Mon, Jul 18, 2011 at 10:44 PM, Alexandre Julliard julliard@winehq.org wrote:
Grazvydas Ignotas notasas@gmail.com writes:
It looks like the best way would be to attach state to handle somehow (that would be dropped automatically on CloseHandle), but I failed to find a way to do so.
You can't do that either I'm afraid. It's a tricky problem.
ok, what about expanding fd cache in dlls/ntdll/server.c with some functions to allow attaching a pointer to a handle? That would increase cache memory usage though, but perhaps something else could use this too..
Or maybe scavenge 2 bits from fd_cache_entry.type (currently 6 bits with 9 as max value) and make them caller writable? That would be enough for tracking fake directories sent.
Grazvydas Ignotas notasas@gmail.com writes:
ok, what about expanding fd cache in dlls/ntdll/server.c with some functions to allow attaching a pointer to a handle? That would increase cache memory usage though, but perhaps something else could use this too..
Handles can be shared across processes.
On Tue, Jul 19, 2011 at 12:39 PM, Alexandre Julliard julliard@winehq.org wrote:
Grazvydas Ignotas notasas@gmail.com writes:
ok, what about expanding fd cache in dlls/ntdll/server.c with some functions to allow attaching a pointer to a handle? That would increase cache memory usage though, but perhaps something else could use this too..
Handles can be shared across processes.
What about abusing F_GETFD/F_SETFD FD_CLOEXEC flag on file descriptor then?
Grazvydas Ignotas notasas@gmail.com writes:
What about abusing F_GETFD/F_SETFD FD_CLOEXEC flag on file descriptor then?
No, we need it to be always set.
Here is another idea:
It seems getdents64 is indeed returning "." and "..", but not necessarily first, like Windows does. I think we could swap first 2 entries returned, whatever they are, with "." and "..". It would work like this:
- read the 2 first entries to advance file pointer, but ignore them, return "." or ".." instead - return other entries normally - after "." or ".." is encountered, save current file offset and seek to first or second entry (respectively) and return that instead. For a corner case where that spot has ".." or ".", return the other one of first 2. - seek back where we were
I think this would also fix fake_dot_dot + single_entry case. What do you think?
Grazvydas Ignotas notasas@gmail.com writes:
Here is another idea:
It seems getdents64 is indeed returning "." and "..", but not necessarily first, like Windows does. I think we could swap first 2 entries returned, whatever they are, with "." and "..". It would work like this:
- read the 2 first entries to advance file pointer, but ignore them,
return "." or ".." instead
- return other entries normally
- after "." or ".." is encountered, save current file offset and seek
to first or second entry (respectively) and return that instead. For a corner case where that spot has ".." or ".", return the other one of first 2.
- seek back where we were
I think this would also fix fake_dot_dot + single_entry case. What do you think?
That could probably be made to work, yes.
On Wed, Jul 20, 2011 at 07:29:13PM +0200, Alexandre Julliard wrote:
Grazvydas Ignotas notasas@gmail.com writes:
Here is another idea:
It seems getdents64 is indeed returning "." and "..", but not necessarily first, like Windows does. I think we could swap first 2 entries returned, whatever they are, with "." and "..". It would work like this:
- read the 2 first entries to advance file pointer, but ignore them,
return "." or ".." instead
- return other entries normally
- after "." or ".." is encountered, save current file offset and seek
to first or second entry (respectively) and return that instead. For a corner case where that spot has ".." or ".", return the other one of first 2.
- seek back where we were
I think this would also fix fake_dot_dot + single_entry case. What do you think?
That could probably be made to work, yes.
Remember that you can only seek to the offsets returned by the OS. Directory offsets aren't necessarily byte offsets. (They may be 64bit values even for small directories.)
David
-
Alexandre Julliard -
David Laight -
Farmboy0 -
Grazvydas Ignotas