From b037f324aa531201a8ef6d1b4dc56efed622a12e Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Tue, 28 Jan 2014 16:01:19 -0400 Subject: rework annexed object locking in direct mode & support Windows Seems that locking of annexed objects when they're being dropped was broken in direct mode: * When taking the lock before dropping, it created the .git/annex/objects file, as an empty file. It seems that the dropping code deleted that, but that is not right, and for all I know could in some situation cause a corrupted object to leak out. * When the lock was checked, it actually tried to open each direct mode file, and checked if it was locked. Not the same lock used above, and could also fail if some consumer of the file locked it. Fixed this, and added windows support by switching direct mode to lock a .lck file. --- doc/todo/windows_support.mdwn | 2 -- 1 file changed, 2 deletions(-) (limited to 'doc/todo/windows_support.mdwn') diff --git a/doc/todo/windows_support.mdwn b/doc/todo/windows_support.mdwn index fea8241cc..c7aa402e3 100644 --- a/doc/todo/windows_support.mdwn +++ b/doc/todo/windows_support.mdwn @@ -7,8 +7,6 @@ now! --[[Joey]] support use of DOS style paths, which git-annex uses on Windows). Must use Msysgit. * rsync special remotes are known buggy. -* Bad file locking, it's probably not safe to run more than one git-annex - process at the same time on Windows. * Ssh connection caching does not work on Windows, so `git annex get` has to connect twice to the remote system over ssh per file, which is much slower than on systems supporting connection caching. -- cgit v1.2.3