Re: server: implement move/rename change notifications and support for multiple change notification in one reply
On Tue, Dec 16, 2008 at 5:21 PM, Michael Pujos pujos.michael@laposte.net wrote:
I don't see an attachment to http://www.winehq.org/pipermail/wine-patches/2008-December/066224.html or rather, there's only a zero-length one.
I just attached (In thunderbird) the file outputted by "git format-patch --keep-subject origin" Curiously the link above point to a zero length file but I received it correctly in my e-mail client from the mailing-list...
That archive is a bit finicky. I see the attachment in another archive: http://marc.info/?l=wine-patches&m=122947592925831&w=2 Suggestion: next time use a shorter filename, maybe that's what screwed up the archive.
It looks like you're changing the protocol. Will old clients be able to connect successfully? It looks like they won't. you need to support old clients. We're not allowed to break compatibility now that we've released wine-1.0. - Dan
Dan Kegel wrote:
On Tue, Dec 16, 2008 at 5:21 PM, Michael Pujos pujos.michael@laposte.net wrote:
I don't see an attachment to http://www.winehq.org/pipermail/wine-patches/2008-December/066224.html or rather, there's only a zero-length one.
I just attached (In thunderbird) the file outputted by "git format-patch --keep-subject origin" Curiously the link above point to a zero length file but I received it correctly in my e-mail client from the mailing-list...
That archive is a bit finicky. I see the attachment in another archive: http://marc.info/?l=wine-patches&m=122947592925831&w=2 Suggestion: next time use a shorter filename, maybe that's what screwed up the archive.
Ah ok, I've noticed it also happens with other patches posted
It looks like you're changing the protocol. Will old clients be able to connect successfully? It looks like they won't. you need to support old clients. We're not allowed to break compatibility now that we've released wine-1.0.
- Dan
The protocol is slightly changed between read_changes_apc() in ntdll and the server to support return of multiple FILE_NOTIFY_INFORMATION structs at a time. This is transparent to win32 programs (is that what you are calling client ? 'm still a bit new to wine terminology :). using this API (ReadDirectoryChangeW) and I took great care to have all the tests pass.
On Tue, Dec 16, 2008 at 5:40 PM, Michael Pujos pujos.michael@laposte.net wrote:
The protocol is slightly changed between read_changes_apc() in ntdll and the server to support return of multiple FILE_NOTIFY_INFORMATION structs at a time. This is transparent to win32 programs (is that what you are calling client ? 'm still a bit new to wine terminology :)
Yes, any wine app is a client of the wineserver.
using this API (ReadDirectoryChangeW) and I took great care to have all the tests pass.
Oh, I guess you're right... I keep forgetting that the software on both ends will get updated at the same time. This is discussed in http://bugs.winehq.org/show_bug.cgi?id=124 - Dan
2008/12/17 Dan Kegel dank@kegel.com:
On Tue, Dec 16, 2008 at 5:21 PM, Michael Pujos pujos.michael@laposte.net wrote:
I don't see an attachment to http://www.winehq.org/pipermail/wine-patches/2008-December/066224.html or rather, there's only a zero-length one.
I just attached (In thunderbird) the file outputted by "git format-patch --keep-subject origin" Curiously the link above point to a zero length file but I received it correctly in my e-mail client from the mailing-list...
That archive is a bit finicky. I see the attachment in another archive: http://marc.info/?l=wine-patches&m=122947592925831&w=2 Suggestion: next time use a shorter filename, maybe that's what screwed up the archive.
The attachment is here: http://www.winehq.org/pipermail/wine-patches/2008-December/066225.html The archive seems to create separate mails for attached mails.
On Wed, Dec 17, 2008 at 1:21 AM, Henri Verbeet hverbeet@gmail.com wrote:
The attachment is here: http://www.winehq.org/pipermail/wine-patches/2008-December/066225.html The archive seems to create separate mails for attached mails.
D'oh! Geez, we've got to fix that... - Dan
-
Dan Kegel -
Henri Verbeet -
Michael Pujos