> -----Original Message-----
> From: Dirck Blaskey [mailto:listtarget2_at_danbala.com]
> Sent: donderdag 25 september 2008 23:31
> To: dev_at_subversion.tigris.org
> Subject: explaining inexplicable delay in svn diff
>
> Recently upgraded to svn client 1.5.2, and all of a sudden simple diff
> commands take 12+ seconds.
> Using sysinternals processmonitor, it looks like svn is trying to
> create
> a file "tmp" in the TEMP folder;
> in my case (for some reason) there was already a folder called "tmp" in
> the TEMP folder, so
> svn burns about 12 seconds trying again repeatedly, until it moves on
> and tries tmp.2.
>
> If there is a file called "tmp" instead of a folder, it gets a name
> collision and moves on to tmp.2.
>
> Maybe you could check for the "IS DIRECTORY" result from CreateFile and
> not sit and spin.
>
> Here's some of the log from procmon:
>
> starts playing in the temp folder
>
> "41095","2:07:55.3374974
> PM","svn.exe","3716","CreateFile","D:\temp","SUCCESS","Desired Access:
> Read Attributes, Synchronize, Disposition: Open, Options: Synchronous
> IO
> Non-Alert, Attributes: n/a, ShareMode: Read, Write, Delete,
> AllocationSize: n/a, OpenResult: Opened"
> "41096","2:07:55.3375524
> PM","svn.exe","3716","QueryInformationVolume","D:\temp","BUFFER
> OVERFLOW","VolumeCreationTime: 4/29/2006 12:22:33 PM,
> VolumeSerialNumber: BC46-4855, SupportsObjects: True, VolumeLabel:
> dat?"
> "41097","2:07:55.3375894
> PM","svn.exe","3716","QueryAllInformationFile","D:\temp","BUFFER
> OVERFLOW","CreationTime: 4/30/2006 1:58:17 PM, LastAccessTime:
> 9/25/2008
> 2:07:21 PM, LastWriteTime: 9/25/2008 2:07:21 PM, ChangeTime: 9/25/2008
> 2:07:21 PM, FileAttributes: D, AllocationSize: 0, EndOfFile: 0,
> NumberOfLinks: 1, DeletePending: False, Directory: True, IndexNumber:
> 0x500000000497d, EaSize: 0, Access: Read Attributes, Synchronize,
> Position: 0, Mode: Synchronous IO Non-Alert, AlignmentRequirement:
> Word"
> "41098","2:07:55.3376282
> PM","svn.exe","3716","CloseFile","D:\temp","SUCCESS",""
> "41100","2:07:55.3377366
> PM","svn.exe","3716","CreateFile","D:\temp\apr-
> tmp.bQ1jpe","SUCCESS","Desired
> Access: Generic Read/Write, Delete, Disposition: Create, Options:
> Synchronous IO Non-Alert, Non-Directory File, Delete On Close,
> Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: 0,
> OpenResult: Created"
> "41101","2:07:55.3379078
> PM","svn.exe","3716","WriteFile","D:\temp\apr-
> tmp.bQ1jpe","SUCCESS","Offset:
> 0, Length: 1"
> "41102","2:07:55.3380203
> PM","svn.exe","3716","CloseFile","D:\temp\apr-tmp.bQ1jpe","SUCCESS",""
> "41103","2:07:55.3381749
> PM","svn.exe","3716","CreateFile","D:\temp\tmp","IS DIRECTORY","Desired
> Access: Generic Read/Write, Disposition: Create, Options: Synchronous
> IO
> Non-Alert, Non-Directory File, Attributes: n/a, ShareMode: Read, Write,
> Delete, AllocationSize: 0"
>
> last entry repeats 100 or so times, then it tries again read only:
My guess is that it repeats 101 times; the actual action (1) and 100 WIN32
specific retries.
This is what the WIN32_RETRY_LOOP() in subversion/libsvn_subr/io.c does.
This code is used to work around issues caused by open files of other
applications (In my tests mostly Virus Scanners and tsvncache. That last one
sometimes keeps a file monitor open on workingcopies previously opened in
the windows explorer).
Just retrying failed actions might help in some cases, but is severely
broken in others, like this.
(I just remembered
http://blogs.msdn.com/oldnewthing/archive/2005/11/07/489807.aspx )
I think there was some talking on introducing a few new retry loops this
week. (The '[PATCH] Working copy on Samba share' thread).
In my opinion just retrying when you think it might perhaps fix a few user
issues is not the right thing to do. Especially if you don't check for
specific errors, like our current WIN32_RETRY_LOOP() that uses the same
check on all places where it is used.
For this specific case: To get a unique temp file, I think we shouldn't
retry at all. It's better to retry with a different tempname.
Bert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-09-26 15:58:00 CEST