All of lore.kernel.org
 help / color / mirror / Atom feed
From: Robert Yang <liezhi.yang@windriver.com>
To: Richard Purdie <richard.purdie@linuxfoundation.org>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [PATCH 1/1] sstate.bbclass: update the timestamps after install
Date: Thu, 4 Sep 2014 18:27:35 +0800	[thread overview]
Message-ID: <54083E97.9000005@windriver.com> (raw)
In-Reply-To: <1409820816.12482.30.camel@ted>



On 09/04/2014 04:53 PM, Richard Purdie wrote:
> On Thu, 2014-09-04 at 16:49 +0800, Robert Yang wrote:
>>
>> On 09/04/2014 04:27 PM, Richard Purdie wrote:
>>> On Thu, 2014-09-04 at 00:05 -0700, Robert Yang wrote:
>>>> Update the sstate file's timestamps after it is installed, it will be
>>>> very useful for removing the old sstate file, especially, it's not easy
>>>> to remove when use the shared SSTATE_DIR, we can easily remove them with
>>>> this change, for example:
>>>>
>>>> $ find state-cache -type f -ctime +10 -exec rm -f {} \;
>>>>
>>>> Will remove the sstate file which isn't used by recent 10 days.
>>>>
>>>> We can use the -atime, but it is not always available, for example,
>>>> when mounted with "-o noatime".
>>>>
>>>> The touch is a very light weight action, and the
>>>> scripts/sstate-cache-management.sh also requires this.
>>>>
>>>> Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
>>>> ---
>>>>    meta/classes/sstate.bbclass |    1 +
>>>>    1 file changed, 1 insertion(+)
>>>>
>>>> diff --git a/meta/classes/sstate.bbclass b/meta/classes/sstate.bbclass
>>>> index ead829e..885912d 100644
>>>> --- a/meta/classes/sstate.bbclass
>>>> +++ b/meta/classes/sstate.bbclass
>>>> @@ -618,6 +618,7 @@ sstate_unpack_package () {
>>>>    	mkdir -p ${SSTATE_INSTDIR}
>>>>    	cd ${SSTATE_INSTDIR}
>>>>    	tar -xmvzf ${SSTATE_PKG}
>>>> +	touch --no-dereference ${SSTATE_PKG}
>>>>    }
>>>>
>>>>    BB_HASHCHECK_FUNCTION = "sstate_checkhashes"
>>>
>>> At the very least we need to consider read only files here...
>>
>> Hello, did you mean the SSTATE_MIRRORS ? I thought that I had
>> considered it since I used the "touch --no-dereference",
>> make a clear check is reasonable if I understand correctly,
>> so updated the code in the repo: (The --no-dereference is not
>> need any more since the "test -w" follows symlink).
>
> We need the --no-dereferece but this could also be a readonly directory

Under more thoughts, yes, we need the --no-dereferece otherwise the
touch may update the file in the SSTATE_MIRRORS, and it's safe to touch
a symlink itself (though "test -w" follows symlink) since the permissions
of symbolic links are never used.

For readonly_dir/ssfile, we can touch the ssfile if "test -w ssfile",
it doesn't care about the dir's write permission. Or do we have to
check the permission of "dirname ${SSTATE_PKG}" and ${SSTATE_DIR} ?
I don't think that we need unless it causes errors.

For the ISO, the "test -w {SSTATE_PKG}" would fail so that no touch,
here is the updated code, also in the repo:

diff --git a/meta/classes/sstate.bbclass b/meta/classes/sstate.bbclass
index ead829e..78766c0 100644
--- a/meta/classes/sstate.bbclass
+++ b/meta/classes/sstate.bbclass
@@ -618,6 +618,8 @@ sstate_unpack_package () {
         mkdir -p ${SSTATE_INSTDIR}
         cd ${SSTATE_INSTDIR}
         tar -xmvzf ${SSTATE_PKG}
+       # Use "! -w ||" to return true for read only files
+       [ ! -w ${SSTATE_PKG} ] || touch ${SSTATE_PKG}
  }

// Robert

> or set of readonly files (think an ISO shipped with WR Linux or locked
> sstate cache).
>
> Cheers,
>
> Richard
>
>
>


  reply	other threads:[~2014-09-04 10:28 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-04  7:05 [PATCH 0/1] sstate.bbclass: update the timestamps after install Robert Yang
2014-09-04  7:05 ` [PATCH 1/1] " Robert Yang
2014-09-04  8:27   ` Richard Purdie
2014-09-04  8:49     ` Robert Yang
2014-09-04  8:53       ` Richard Purdie
2014-09-04 10:27         ` Robert Yang [this message]
2014-09-04 10:29           ` Robert Yang
2014-09-24 22:37           ` Burton, Ross
2014-09-25  2:32             ` Robert Yang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=54083E97.9000005@windriver.com \
    --to=liezhi.yang@windriver.com \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=richard.purdie@linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.