Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Robert Yang <liezhi.yang@windriver.com>
To: Seebs <seebs@seebs.net>,
	oe-core <openembedded-core@lists.openembedded.org>
Subject: Re: About pseudo's chmod
Date: Tue, 2 Aug 2016 16:32:06 +0800	[thread overview]
Message-ID: <57A05A86.7000701@windriver.com> (raw)
In-Reply-To: <9BFBB743-6513-4791-9046-6BFBED50A347@seebs.net>



On 08/02/2016 02:50 PM, Seebs wrote:
> On 2 Aug 2016, at 1:44, Robert Yang wrote:
>
>> Because the stat() gets 0644 on ${B}/version.c in the second run, so it
>> would run chmod 0644 rather than 0444 on gzip-dbg/version.c.
>
> Why is it calling chmod at all? The goal is apparently to give
> gzip-dbg/version.c the same mode that ${B}/version.c has. Since it's a
> hard link, no chmod call is needed at all.

It is worth trying, I will try to remove os.chown() and os.chmod() from
package.bbclass to see what will happen:

             if not cpath.islink(file):
                 os.link(file, fpath)
                 fstat = cpath.stat(file)
                 os.chmod(fpath, fstat.st_mode)
                 os.chown(fpath, fstat.st_uid, fstat.st_gid)

>
>>> time and not the second? If it does it the second time, the fact that
>>> the underlying file's mode changed won't matter.
>>>
>>> But in this case... While I'm fine with modifying things to track the
>>
>> Thanks, I will send a patch for it.
>
> I already have a patch for this.
>
>>> file linked-to, it still feels like this is a usage error. Fundamentally,
>>> we're unpacking a file (${B}/version.c), then linking to it, changing
>>> the link in some way, deleting the link, and expecting the original file
>>> to be unchanged. That doesn't seem right to me.
>
>> But that is what the real filesystem works without pseudo:
>> $ touch file1
>> $ ln file1 file2
>> $ chmod 777 file2
>> $ rm -f file2
>>
>> file1 will be 777 on the real filesystem.
>
> Yes. But it seems that the mode the file is being changed to is dependant on the
> original reported mode. And that's the part that I'm confused by;
> we're relying on the mode of the original file, but we're also changing
> the mode of a hard link to it. This makes no sense to me.
>
> So, I have a likely fix handy. (The difference between mine and the
> version you proposed earlier is that, as I recall, yours does the LINK
> operation on the original file unconditionally, which is in error; it

I had checked pseudo's source code, I didn't find any function that can check
this, and I appreciated that if you can fix it:-).

// Robert

> should only be done when no existing data was found in the database.) I'll
> double-check that again and go through looking for loose ends, because
> I have a vague feeling that I'm overlooking a thing, but I haven't figured out
> what it would be yet.
>
> -s


  reply	other threads:[~2016-08-02  8:32 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-05 10:23 About pseudo's chmod Robert Yang
2016-07-05 13:10 ` Mark Hatle
2016-07-05 14:10   ` Robert Yang
2016-07-29  7:38   ` Robert Yang
2016-07-29  7:40     ` Robert Yang
2016-07-29 16:02     ` Seebs
2016-08-01  5:57       ` Robert Yang
2016-08-01  8:42         ` Seebs
2016-08-01  8:57           ` Robert Yang
2016-08-01 18:17             ` Seebs
2016-08-01 20:01               ` Richard Purdie
2016-08-01 20:17                 ` Seebs
2016-08-01 22:55                   ` Richard Purdie
2016-08-01 23:36                     ` Mark Hatle
2016-08-02  3:39                       ` Seebs
2016-08-02  1:52                     ` Robert Yang
2016-08-02  3:43                       ` Seebs
2016-08-02  6:07                         ` Robert Yang
2016-08-02  6:08                           ` Robert Yang
2016-08-02  6:30                           ` Seebs
2016-08-02  6:44                             ` Robert Yang
2016-08-02  6:50                               ` Seebs
2016-08-02  8:32                                 ` Robert Yang [this message]
2016-08-02 19:16                                   ` Seebs
2016-08-02 19:18                                     ` Burton, Ross
2016-08-02 15:12                                 ` Mark Hatle
2016-08-02 19:19                                   ` Seebs
2016-08-02 19:39                                     ` Mark Hatle
2016-08-02 19:53                                       ` Seebs
2016-08-02  3:37                     ` Seebs

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=57A05A86.7000701@windriver.com \
    --to=liezhi.yang@windriver.com \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=seebs@seebs.net \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox