[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

bug report, file copy performance

From: Ty Baen-Price <tbaen_at_wynyardgroup.com>
Date: Sun, 6 Sep 2015 23:05:56 +0000

Hi,

I've checked the issue tracker, and the changelog, but not the mailing list archive (it was scary).
I'm on version 1.9.0, but this issue has affected me for many versions. I'm also on Win 8.1, in case that's relevant.
I am running on a reasonably high-spec'ed machine, so the issue is not due to inferior hardware capability.

I am a software dev, and I regularly move/ copy moderate numbers of files (say, 100 to 1000) from one place to another, including over a network.
I have noticed that whenever I perform either a drag and drop operation (almost always solely left-click), or a ctrl + c, ctrl + v copy of a selection of files (it makes no difference whether the files are in an svn repo), I have to wait a long time for the actual copy operation to begin, sometimes minutes. I have also noticed this effect when copying less than 10 files from a network location to my local machine. Visible during this time is that in both explorer windows (source and destination), a mouseover will usually change the cursor to the Windows spinny waiting thing, and clicks will cause the "(not responding)" text to be displayed in the title bar.

I have performed superficial examinations of sequential process dumps taken of explorer.exe during the freezes, using Tortoise trunk source and Tortoise's symbol server, and determined Tortoise to be the likely cause of this issue. I will paste the relevant call stacks below. It would seem that the basic problem is that Tortoise performs its context menu population for shell events it's probably not intrested in.

Here is the call stack for a drag and drop copy (from a network location to a local location) of a selection of files (~130 in number), performed entirely with the left mouse button:

Child-SP RetAddr Call Site
ntdll!NtQueryDirectoryFile+0xa
KERNELBASE!FindFirstFileExW+0x290
KERNELBASE!FindFirstFileW+0x1c
kernel32!GetLongPathNameW+0x181
TortoiseSVN!CPathUtils::GetLongPathname+0x2ae [d:\development\svn\releases\tortoisesvn-1.9.0\src\utils\pathutils.cpp @ 384]
TortoiseSVN!CShellExt::Initialize_Wrap+0x465 [d:\development\svn\releases\tortoisesvn-1.9.0\src\tortoiseshell\contextmenu.cpp @ 297]
TortoiseSVN!CShellExt::Initialize+0xd [d:\development\svn\releases\tortoisesvn-1.9.0\src\tortoiseshell\contextmenu.cpp @ 223]
shell32!IShellExtInit_Initialize+0xc7
shell32!HDXA_QueryContextMenu+0x2a3
shell32!HDXA_AppendMenuItems+0x58
shell32!CFSDropTarget::_PopulateDragDropMenu+0x173
shell32!CFSDropTarget::_DragDropMenu+0x87
shell32!CFSDropTarget::Drop+0xa2
shell32!CDVDropTarget::_PerformDrop+0x13a
shell32!CDVDropTarget::Drop+0x292
shell32!CDefView::Drop+0x1a
ole32!CPrivDragDrop::PrivDragDrop+0x1a2 [d:\blue\com\ole32\com\rot\getif.cxx @ 765]
rpcrt4!Invoke+0x73
[snip]
ntdll!RtlUserThreadStart+0x34

Multiple process dumps, taken whole seconds apart, show exactly the same call path active, but with different file names being resolved.

Here is the call stack of a similar copy performed with ctrl+c, ctrl+v:

Child-SP RetAddr Call Site
ntdll!NtQueryDirectoryFile+0xa
KERNELBASE!FindFirstFileExW+0x290
KERNELBASE!FindFirstFileW+0x1c
kernel32!GetLongPathNameW+0x181
TortoiseSVN!CPathUtils::GetLongPathname+0x319 [d:\development\svn\releases\tortoisesvn-1.9.0\src\utils\pathutils.cpp @ 398]
TortoiseSVN!CShellExt::Initialize_Wrap+0x465 [d:\development\svn\releases\tortoisesvn-1.9.0\src\tortoiseshell\contextmenu.cpp @ 297]
TortoiseSVN!CShellExt::Initialize+0xd [d:\development\svn\releases\tortoisesvn-1.9.0\src\tortoiseshell\contextmenu.cpp @ 223]
shell32!IShellExtInit_Initialize+0xc7
shell32!HDXA_QueryContextMenu+0x2a3
shell32!HDXA_AppendMenuItems+0x58
shell32!CFSDropTarget::_PopulateDragDropMenu+0x173
shell32!CFSDropTarget::_DragDropMenu+0x87
shell32!CFSDropTarget::Drop+0xa2
shlwapi!SHSimulateDrop+0xa9
shell32!SHSimulateDropWithSite+0x5b
shell32!SimulateDropWithPasteSucceeded+0x29
shell32!CDefFolderMenu::_ProcessEditPaste+0xd2
shell32!`Microsoft::WRL::Module<1,Microsoft::WRL::Details::DefaultModule<5> >::Create'::`2'::`dynamic atexit destructor for 'module''+0x7a443
shell32!CDefView::_InvokeContextMenu+0x115
shell32!CDefView::_ExplorerCommand+0x1eb
shell32!CDefView::_AllowEditCommand+0x3c
shell32!CDefView::_OnCommand+0x400
shell32!`Microsoft::WRL::Module<1,Microsoft::WRL::Details::DefaultModule<5> >::Create'::`2'::`dynamic atexit destructor for 'module''+0x233ff
shell32!CDefView::s_WndProc+0x56
user32!UserCallWinProcCheckWow+0x149
[snip]
ntdll!RtlUserThreadStart+0x34

In summary:
What I notice is file copy operations on groups of files taking a long time to begin the actual copy.

A partial workaround is to perform operations at the folder level, not the file level, or to use a command prompt.

Regards,
Ty

Ty Baen-Price
JADE Development Team Leader
Wynyard Group

DDI +64 3 367 8453

Powerful Software. Connecting the Dots.
wynyardgroup.com<http://wynyardgroup.com/>

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3136136

To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2015-09-07 07:31:11 CEST

This is an archived mail posted to the TortoiseSVN Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.