Re: [OE-core] About pseudo's chmod

On 2 Aug 2016, at 14:39, Mark Hatle wrote: The alternative to the 'ln' is a 'cp' operation. This is how it used to work until optimizations were added a few releases ago. It was observed that this saves a large amount of space -- but it had the unintended consequence of suddenly files are

Re: [OE-core] About pseudo's chmod

On 8/2/16 2:19 PM, Seebs wrote: > On 2 Aug 2016, at 10:12, Mark Hatle wrote: > >> So the problem is -- pseudo is modifying the 'original' file perms, >> which on a >> new instance of the pseudo database then gets inherited. So we get >> unpredictable results if this is the first time through --

Re: [OE-core] About pseudo's chmod

On 2 Aug 2016, at 10:12, Mark Hatle wrote: So the problem is -- pseudo is modifying the 'original' file perms, which on a new instance of the pseudo database then gets inherited. So we get unpredictable results if this is the first time through -- or not the first time through. Yeah. And

Re: [OE-core] About pseudo's chmod

On 2 August 2016 at 20:16, Seebs wrote: > Does python's os.link work across devices maybe? > The documentation at least says hard link explicitly, so presumably not. Ross -- ___ Openembedded-core mailing list

Re: [OE-core] About pseudo's chmod

On 2 Aug 2016, at 3:32, Robert Yang wrote: > 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) >

Re: [OE-core] About pseudo's chmod

On 8/2/16 1:50 AM, 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 >

Re: [OE-core] About pseudo's chmod

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

Re: [OE-core] About pseudo's chmod

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

Re: [OE-core] About pseudo's chmod

On 08/02/2016 02:30 PM, Seebs wrote: On 2 Aug 2016, at 1:07, Robert Yang wrote: Currently, the problem in oe-core is: 1) bitbake gzip 2) Edit rpm-native or package.bbclass to make do_package re-run. 3) bitbake gzip After the first build, build/version.c in gzip-dbg

Re: [OE-core] About pseudo's chmod

On 2 Aug 2016, at 1:07, Robert Yang wrote: Currently, the problem in oe-core is: 1) bitbake gzip 2) Edit rpm-native or package.bbclass to make do_package re-run. 3) bitbake gzip After the first build, build/version.c in gzip-dbg is 0444, but after the second

Re: [OE-core] About pseudo's chmod

On 08/02/2016 02:07 PM, Robert Yang wrote: On 08/02/2016 11:43 AM, Seebs wrote: On 1 Aug 2016, at 20:52, Robert Yang wrote: And when remove file2, but file1's permission is changed, it should be considered as a bug. I'm not sure of that. My interpretation would be that hard linking

Re: [OE-core] About pseudo's chmod

On 08/02/2016 11:43 AM, Seebs wrote: On 1 Aug 2016, at 20:52, Robert Yang wrote: And when remove file2, but file1's permission is changed, it should be considered as a bug. I'm not sure of that. My interpretation would be that hard linking under pseudo to files which weren't created under

Re: [OE-core] About pseudo's chmod

On 1 Aug 2016, at 20:52, Robert Yang wrote: And when remove file2, but file1's permission is changed, it should be considered as a bug. I'm not sure of that. My interpretation would be that hard linking under pseudo to files which weren't created under the same pseudo database is user error;

Re: [OE-core] About pseudo's chmod

On 1 Aug 2016, at 18:36, Mark Hatle wrote: Would it makes sense to track the xattrs and linked files and such using some type of inode reference (virtual or otherwise)? Since in the case of a hard link, on a normal Linux style filesystem, there will be a single inode that has a reference

Re: [OE-core] About pseudo's chmod

On 1 Aug 2016, at 17:55, Richard Purdie wrote: The trouble is that for speed, we do create trees of hardlinked files and play games with those and sstate amongst other things. Yeah. One concern would be ownership: If the things we're hardlinking to weren't created/tracked by pseudo initially,

Re: [OE-core] About pseudo's chmod

On 08/02/2016 06:55 AM, Richard Purdie wrote: On Mon, 2016-08-01 at 15:17 -0500, Seebs wrote: On 1 Aug 2016, at 15:01, Richard Purdie wrote: No, we're actually expecting it to retain the mode it was given via the hardlink under pseudo. This is what a real world system would do and in this

Re: [OE-core] About pseudo's chmod

On 8/1/16 5:55 PM, Richard Purdie wrote: > On Mon, 2016-08-01 at 15:17 -0500, Seebs wrote: >> On 1 Aug 2016, at 15:01, Richard Purdie wrote: >> >>> No, we're actually expecting it to retain the mode it was given via >>> the >>> hardlink under pseudo. >>> >>> This is what a real world system would

Re: [OE-core] About pseudo's chmod

On Mon, 2016-08-01 at 15:17 -0500, Seebs wrote: > On 1 Aug 2016, at 15:01, Richard Purdie wrote: > > > No, we're actually expecting it to retain the mode it was given via > > the > > hardlink under pseudo. > > > > This is what a real world system would do and in this case we could > > track it

Re: [OE-core] About pseudo's chmod

On 1 Aug 2016, at 15:01, Richard Purdie wrote: No, we're actually expecting it to retain the mode it was given via the hardlink under pseudo. This is what a real world system would do and in this case we could track it via pseudo since pseudo is loaded when the hardlink is created. It would

Re: [OE-core] About pseudo's chmod

On Mon, 2016-08-01 at 13:17 -0500, Seebs wrote: > On 1 Aug 2016, at 3:57, Robert Yang wrote: > > > How about we track the src when hardlink, for example: > > I don't think I like this. > > Fundamentally, the problem here is making a hard link to a file > outside > of pseudo, and then modifying

Re: [OE-core] About pseudo's chmod

On 1 Aug 2016, at 3:57, Robert Yang wrote: How about we track the src when hardlink, for example: I don't think I like this. Fundamentally, the problem here is making a hard link to a file outside of pseudo, and then modifying the file. Consider, if you will, what happens if you replace

Re: [OE-core] About pseudo's chmod

On 08/01/2016 04:42 PM, Seebs wrote: On 1 Aug 2016, at 0:57, Robert Yang wrote: Sorry, the steps were wrong, they should be: 1) Out of pseudo: $ umask 0022 $ touch file1 2) Under pseudo: $ ln file1 file2 $ chmod 777 file2 $ ls -l file1 file2 We can see that both file1 and

Re: [OE-core] About pseudo's chmod

On 1 Aug 2016, at 0:57, Robert Yang wrote: Sorry, the steps were wrong, they should be: 1) Out of pseudo: $ umask 0022 $ touch file1 2) Under pseudo: $ ln file1 file2 $ chmod 777 file2 $ ls -l file1 file2 We can see that both file1 and file2's mode is 0777. But if we remove

Re: [OE-core] About pseudo's chmod

Hi Peter, Thanks for the reply. On 07/30/2016 12:02 AM, Seebs wrote: On 29 Jul 2016, at 2:38, Robert Yang wrote: It got 0644 but not 0444 in the second build was because pseudo's unlink doesn't take core of hard links, for example: $ umask 0022 $ touch file1 $ ln file1 file2 $ chmod 0777

Re: [OE-core] About pseudo's chmod

On 29 Jul 2016, at 2:38, Robert Yang wrote: It got 0644 but not 0444 in the second build was because pseudo's unlink doesn't take core of hard links, for example: $ umask 0022 $ touch file1 $ ln file1 file2 $ chmod 0777 file1 $ ls -l file1 file2 We can see that both file1 and file2's mode is

Re: [OE-core] About pseudo's chmod

On 07/29/2016 03:38 PM, Robert Yang wrote: On 07/05/2016 09:10 PM, Mark Hatle wrote: On 7/5/16 5:23 AM, Robert Yang wrote: Hi, When run "chmod 0444 " under pseudo, it would always adds write permission for real file (and w + x for dir), which means that it runs as "chmod 0644 ". It does

Re: [OE-core] About pseudo's chmod

On 07/05/2016 09:10 PM, Mark Hatle wrote: On 7/5/16 5:23 AM, Robert Yang wrote: Hi, When run "chmod 0444 " under pseudo, it would always adds write permission for real file (and w + x for dir), which means that it runs as "chmod 0644 ". It does this on real file, not record this on pseudo's

Re: [OE-core] About pseudo's chmod

On 07/05/2016 09:10 PM, Mark Hatle wrote: On 7/5/16 5:23 AM, Robert Yang wrote: Hi, When run "chmod 0444 " under pseudo, it would always adds write permission for real file (and w + x for dir), which means that it runs as "chmod 0644 ". It does this on real file, not record this on pseudo's

Re: [OE-core] About pseudo's chmod

On 7/5/16 5:23 AM, Robert Yang wrote: > Hi, > > When run "chmod 0444 " under pseudo, it would always adds > write permission for real file (and w + x for dir), which means that > it runs as "chmod 0644 ". It does this on real file, not record > this on pseudo's database. Here are the code from

[OE-core] About pseudo's chmod

Hi, When run "chmod 0444 " under pseudo, it would always adds write permission for real file (and w + x for dir), which means that it runs as "chmod 0644 ". It does this on real file, not record this on pseudo's database. Here are the code from pseudo: /* Root can read and write files, and