RE: [egit-dev] Retry deletion in LockFile.commit

["Baumgart, Jens" <jens.baumgart@xxxxxxx>]

E.g. DirCache does not know FS. Should DirCache pass FS.DETECTED to the modified LockFile constructor?
FS.DETECTED is used in many places which does not seem to be nice.
--Jens

-----Original Message-----
From: Shawn Pearce [mailto:spearce@xxxxxxxxxxx] 
Sent: Mittwoch, 21. Juli 2010 19:05
To: Baumgart, Jens
Cc: egit-dev@xxxxxxxxxxx
Subject: Re: [egit-dev] Retry deletion in LockFile.commit

On Wed, Jul 21, 2010 at 6:25 AM, Baumgart, Jens <jens.baumgart@xxxxxxx> wrote:
> I want to fix bug 308506.
> As discussed I want to fix the issue by retrying the deletion if the
> deletion of the file ref fails in LockFile.commit.
> The problem is now the following: LockFile does not know FS, so I can't call
> retryFailedLockFileCommit() to find out the running platform.
> The constructor of LockFile could be extended with a boolen parameter
> retryDeletion.
> My question is:  Is the retry logic only required for DirCache.commit or
> should is apply in further usages of LockFile.commit?

We should do it everywhere.  If the LockFile holds the lock, we have
exclusive write access to this item, and the only reason why we can't
do the commit is most likely the real file is still open for reading
and this is a Windows platform.  I would modify the LockFile
constructor to take in the FS, and update the folks who create one to
pass it in.

In particular we want RefDirectoryUpdate, DirCache, GitIndex to do
this retry.  Might as well just do it everywhere as a feature of
LockFile.

-- 
Shawn.