| Commit message (Collapse) | Author | Age |
|---|
| | |
|
| |
|
|
|
|
| |
It started exporting a isSymbolicLink which supports windows. But,
git-annex does no use symlinks on windows yet and this conflicts with the
function by the same name from unix-compat, so hide it.
|
| | |
|
| |
|
|
|
|
| |
Caused by AMP.. Since I've finally upgraded my dev laptop to 7.10,
I may start missing imports that are not needed with it but are with older
versions..
|
| | |
|
| |
|
|
| |
Avoids problems if the program chdirs
|
| |
|
|
|
|
|
|
|
|
|
| |
There's a potential race, but it's detected and just results in the other
process failing to take the side lock, so possibly retrying one second
later on. The race window is quite narrow so the extra delay is minor.
Left the side lock files mode 666 because an interruption can leave a side
lock file created by another user for a shared repository. When this
happens, the non-owning user can't delete it (+t) but can still lock it,
and so the code falls back to acting as it did before this commit.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
And it closes the tmp file before this. I don't know if this will help
avoid lustre's craziness, but it can't hurt..
|
| | |
|
| |
|
|
|
|
| |
This is less portable, since currently sidelocks rely on /dev/shm.
But, I've seen crazy lustre inconsistencies that make me not trust the
link() method at all, so what can you do.
|
| | |
|
| |
|
|
|
|
|
|
| |
I have a strace taken on a lustre filesystem on which link() returned 0,
but didn't actually succeed, since the file already existed.
One of the linux man pages recommended using link followed by checking like
this. I was reading it yesterday, but cannot find it now.
|
| | |
|
| | |
|
| |
|
|
| |
(not actually used anywhere yet)
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
It's only necessary to open a file for write when taking an exclusive lock.
|
| | |
|
| |
|
|
|
| |
Need to differentiate between the lockfile not being locked, and it not
existing.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Also cleaned up the code, avoiding creating a lock file if we're going to
open it for create later anyway.
And, if there's an exception while preparing to lock the file, but not at
the point of actually taking the lock, throw an exception, instead of
silently not locking and pretending to succeed.
And, on Windows, always use lock file, even if the repo somehow got into
indirect mode (maybe with cygwin git..)
|
| | |
|
| | |
|
| |
|
|
|
|
| |
running at once.
As discussed in bug report.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
Note that while before checkTransfer this called getLock with WriteLock,
getLockStatus's use of ReadLock will also notice any exclusive locks.
Since transfer info files are only locked exclusively, never shared,
there is no behavior change.
Also, fixes checkLocked to actually return Just False when the file
exists, but is not locked.
|
| |
|
|
|
|
|
|
| |
Also fixes a test suite failures introduced in recent commits, where
inAnnexSafe failed in indirect mode, since it tried to open the lock file
ReadWrite. This is why the new checkLocked opens it ReadOnly.
This commit was sponsored by Chad Horohoe.
|
| | |
|
|
|
Added a convenience Utility.LockFile that is not a windows/posix
portability shim, but still manages to cut down on the boilerplate around
locking.
This commit was sponsored by Johan Herland.
|
Joey Hess
Joey Hess