Commit 51edde653707e7a3cd2186082458f01f32cd1996 makes a wrong assumption that SSTATE_MIRRORS have write permissions.
A mirror is by definition outside of it's user control. In my use case it happens I does not have permissions to update the access time of the dereferenced symbolic-link file. If we had the possibility to modify the sstate-mirror we would have set SSTATE_DIR instead. There are 3 possible fixes: * Revert this patch. It seems tailored to a very special use case which breaks the definition of mirror. * Only touch the file if the file access time is writeable. * Set (yet) another option to touch SSTATE_MIRROR files. I also can imagine this raising sever performance issues if the mirror is used by several users at the same time. The server will need to update the file meta data every time This patch fixes the bug with minimal impact on the original functionality. Option 2 Related to (https://bugzilla.yoctoproject.org/show_bug.cgi?id=10857) >From aa8cab9660744c8d5277f8e82f10a844884aff78 Mon Sep 17 00:00:00 2001 From: Paulo Neves <paulo.de_sousa_ne...@nokia.com> Date: Tue, 11 Apr 2017 10:57:47 +0300 Subject: [PATCH] Added test for write ability of sstate-mirror .siginfo --- meta/classes/sstate.bbclass | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/classes/sstate.bbclass b/meta/classes/sstate.bbclass index af588548c2ef85d966787df7ae1432e1744bdba6..36cbbd151aa1c93f4ca377b3a23c011a527389d8 100644 --- a/meta/classes/sstate.bbclass +++ b/meta/classes/sstate.bbclass @@ -753,7 +753,7 @@ python sstate_sign_package () { sstate_unpack_package () { tar -xvzf ${SSTATE_PKG} # update .siginfo atime on local/NFS mirror - [ -h ${SSTATE_PKG}.siginfo ] && touch -a ${SSTATE_PKG}.siginfo + [ -w ${SSTATE_PKG}.siginfo ] && [ -h ${SSTATE_PKG}.siginfo ] && touch -a ${SSTATE_PKG}.siginfo # Use "! -w ||" to return true for read only files [ ! -w ${SSTATE_PKG} ] || touch --no-dereference ${SSTATE_PKG} [ ! -w ${SSTATE_PKG}.sig ] || [ ! -e ${SSTATE_PKG}.sig ] || touch --no-dereference ${SSTATE_PKG}.sig -- 2.6.2 Best regards Paulo Neves -- _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto