main/abuild: workaround for fetching files to an nfs share

1 files changed, 47 insertions, 0 deletions

diff --git a/main/abuild/0001-abuild-workaround-with-fetch-lock-file-on-nfs.patch b/main/abuild/0001-abuild-workaround-with-fetch-lock-file-on-nfs.patch
new file mode 100644
index 0000000000..83a79f09b6
--- /dev/null
+++ b/main/abuild/0001-abuild-workaround-with-fetch-lock-file-on-nfs.patch
@@ -0,0 +1,47 @@
+From 8468825035d1c0af12abbb67aea85260cd048946 Mon Sep 17 00:00:00 2001
+From: Natanael Copa <ncopa@alpinelinux.org>
+Date: Wed, 26 Aug 2015 08:14:36 +0200
+Subject: [PATCH] abuild: workaround with fetch lock file on nfs
+
+flock(2) on an NFS mount will on the server side convert the lock to a
+POSIX lock (fcntl(F_SETLK)). This means that abuild running on NFS
+server and client will create different locks and they will both try
+download same file at same time.
+
+The proper fix would be to patch curl to have an option to create a
+posix lock for the downlaoded file or create a flock -c like wrapper
+that creates posix lock.
+
+Meanwhile, we implement a stupid test for existance of the lockfile
+before we go on. This is not race-safe because other process could
+create the lockfile after the [ -e $lockfile ] test and before the file
+is created.
+
+At least it is not worse that no locking at all.
+---
+ abuild.in | 9 +++++++++
+ 1 file changed, 9 insertions(+)
+
+diff --git a/abuild.in b/abuild.in
+index b8d8851..f01fe2b 100644
+--- a/abuild.in
++++ b/abuild.in
+@@ -342,6 +342,15 @@ uri_fetch() {
+ 	mkdir -p "$SRCDEST"
+ 
+ 	CLEANUP_FILES="$CLEANUP_FILES $lockfile"
++
++	# best-effort workaround for NFS which has issues with flock
++	if [ -e "$lockfile" ]; then
++		msg "Waiting for ${lockfile##*/}..."
++		while [ -e "$lockfile" ]; do
++			sleep 0.5s
++		done
++	fi
++
+ 	(
+ 	flock -n -x 9 || msg "Waiting for ${lockfile##*/}..."
+ 	flock -x 9
+-- 
+2.5.0
+