As title, dragging a file from the TortoiseSVN repo browser (v1.9.2) onto Dopus creates a zero length file. This bug exists in all versions from Dopus11 to 12.4. OS is 64 bit Windows 7.
1 Like
We will add a workaround for this, but the bug looks like it is on the TortoiseSVN side. (CORRECTION: It's not a bug on the TSVN side, but part of the API standard.)
Its drag & drop data object is giving out streams which are initially positioned at the end of the data. Most likely the data was written into the stream by the drop source (TSVN) and then the position was not reset to the start before the source handed the stream to the drop target (Opus).
I have reported this to the TSVN devs to see what they think. It's possible there is something in the drag & drop spec which we are not aware of, but I suspect this is something that has been overlooked on their side.
Either way, the issue should no longer affect Opus after the next update (12.5), as we've added code to prevent it.
1 Like
Excellent, thank you.
As I understand the documentation, IDataObject::GetData() has to seek the stream to the end before returning it.
When the transfer medium is a stream, OLE makes assumptions about where the data is being returned and the position of the stream's seek pointer. In a GetData call, the data returned is from stream position zero through just before the current seek pointer of the stream (that is, the position on exit).
Also here's a more detailed description about this:
1 Like
I stand corrected. Many thanks for pointing those out!
I'm surprised by the design and could argue against it all day (given the cases where it can't work, as discussed in the 2nd link, and that the data size is provided via the data object's file descriptor), but if that's what the API says then we have to support it (as well as the cases where sources do the opposite as they have no other choice).
In that case, we will make the change on the Opus side for all drop sources, not just as a special case for TSVN.
Apologies for thinking the problem was on TSVN's side and not ours!
No problem 
I did it wrong too the first time, until someone pointed it out to me. To be exact: this was fixed in TortoiseSVN on September 32 in 2014. Which means it was fixed/changed in TortoiseSVN 1.8.9.
1 Like
The fix for this is in beta 12.4.3.