Many IO exceptions on cloning about git-tfs

[spraints]

I agree, they don't seem normal. I wonder what's using those files. Do you have an indexer (e.g. Windows search or google desktop search) running?

[ivan-danilov]

I just checked with procexplorer from SysInternals package. Files in C:\Users\idanilov\AppData\Local\Temp\2\ folder are opened only by git-tfs.exe processes.
[But there're many git-tfs.exe. Couldn't they conflict with each other? --- oops, that's not right. Looked to wrong place]

Btw, cloning is moving forward nevertheless. Slooowly. In the folder there're something about 10k files ~500 MB currently. Two bytes for distinguish temp files, huh? I wonder what will happen when there're more that 65536 :)

UPD: Procmon also shows that deletions are there and they are successfull:

Operation details:

Date & Time: 20.06.2011 23:02:24
Event Class: File System
Operation: SetDispositionInformationFile
Result: SUCCESS
Path: C:\Users\idanilov\AppData\Local\Temp\2\tmpBC04.tmp
TID: 2820
Duration: 0.0000059
Delete: True

Process info

Description: GitTfs
Company: SEP
Name: git-tfs.exe
Version: 0.11.0.0
Path: c:\Program Files (x86)\GitTfs\git-tfs.exe
Command Line: git-tfs clone -d http://tfs:8080/tfs $/Proj/ProjFolder/SRC
PID: 2228
Parent PID: 3604
Session ID: 2
User: domain\idanilov
Auth ID: 00000000:00c38135
Architecture: 32-bit
Virtualized: False
Integrity: High
Started: 20.06.2011 18:14:58
Ended: (Running)

[ivan-danilov]

All those files were left. I've just came to office and checked server. Clone is finished, but temp has 3 GB files in it. Deleted manually.

[spraints]

There should only be as many git-tfs.exe as you are running. If you ran git tfs clone http://x/y/z $/a & git tfs clone http://x/y/z $/a, you'd have two git-tfs.exe processes, but they shouldn't have any temp file conflicts... the only conflict I would expect would be over lock files that git makes when messing with the index.

The thing about indexers is that they access each file very quickly, so it's really hard to detect them with processexplorer, but they have a knack for reading files while you're trying to delete them. I would have hoped that indexers would ignore Temp, but I don't write the indexers.

If git-tfs still has the files open when it tries to delete them, that would also prevent git-tfs from deleting the files, and that would be a bug.

And that is the practical implication of the error you saw: lots of temp files left around for you to manually delete.

[ivan-danilov]

No-no, there was just one git-tfs.exe - as I've pointed it was my error.

[ivan-danilov]

Matt, I've found the problem. Look at https://github.com/spraints/git-tfs/blob/master/GitTfs/Util/TemporaryFile.cs#L53
It is calling Dispose() on base, but it should also call Dispose() on _baseStream.

I will fix it now and close the issue afterwards.

[spraints]

Cool. Thanks for tracking that down.

On Fri, Aug 5, 2011 at 7:03 PM, ivan-danilov
[email protected]
wrote:

Matt, I've found the problem. Look at https://github.com/spraints/git-tfs/blob/master/GitTfs/Util/TemporaryFile.cs#L53
It is calling Dispose() on base, but it should also call Dispose() on _baseStream.

I will fix it now and close the issue afterwards.

Reply to this email directly or view it on GitHub:
https://github.com/spraints/git-tfs/issues/55#issuecomment-1739777