All of lore.kernel.org
 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 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.