# Re: [4/5] Add option for hardlinkable cache of extracted blobs 10 messages from 2005-04-17 to 2005-04-18. Participants: Petr Baudis, Daniel Barkalow, Russell King, Linus Torvalds, Paul Jackson. Thread: https://gitlist.dev/t/90 ## Petr Baudis, 2005-04-17 19:59 Subject: Re: [4/5] Add option for hardlinkable cache of extracted blobs Message-ID: <20050417195935.GI1461@pasky.ji.cz> URL: https://gitlist.dev/e/20050417195935.GI1461%40pasky.ji.cz In-Reply-To: <20050417122517.4b12faea.pj@sgi.com> ``` Dear diary, on Sun, Apr 17, 2005 at 09:25:17PM CEST, I got a letter where Paul Jackson told me that... > Petr wrote: > > BTW, I'd just use access(F_OK) instead of stat() it I don't care about > > I recommend _only_ using it when you require exactly the above real vs. > effective id behaviour. Does this distinction have any effect when doing F_OK? -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor ``` ## Daniel Barkalow, 2005-04-17 20:03 Subject: Re: [4/5] Add option for hardlinkable cache of extracted blobs Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.21.0504171600310.30848-100000%40iabervon.org In-Reply-To: <20050417195935.GI1461@pasky.ji.cz> ``` On Sun, 17 Apr 2005, Petr Baudis wrote: > Dear diary, on Sun, Apr 17, 2005 at 09:25:17PM CEST, I got a letter > where Paul Jackson told me that... > > Petr wrote: > > > BTW, I'd just use access(F_OK) instead of stat() it I don't care about > > > > I recommend _only_ using it when you require exactly the above real vs. > > effective id behaviour. > > Does this distinction have any effect when doing F_OK? Actually, the documentation I've got says: "F_OK requests checking whether merely testing for the existence of the file would be allowed (this depends on the permissions of the directories in the path to the file, as given in path-name.)" So it shouldn't complain about a filename which you're allowed to try to stat, even if there's nothing there. And it would depend on the privs of the wrong user in looking at the path. -Daniel *This .sig left intentionally blank* ``` ## Petr Baudis, 2005-04-17 20:18 Subject: Re: [4/5] Add option for hardlinkable cache of extracted blobs Message-ID: <20050417201856.GJ1461@pasky.ji.cz> URL: https://gitlist.dev/e/20050417201856.GJ1461%40pasky.ji.cz In-Reply-To: ``` Dear diary, on Sun, Apr 17, 2005 at 10:03:46PM CEST, I got a letter where Daniel Barkalow told me that... > On Sun, 17 Apr 2005, Petr Baudis wrote: > > > Dear diary, on Sun, Apr 17, 2005 at 09:25:17PM CEST, I got a letter > > where Paul Jackson told me that... > > > Petr wrote: > > > > BTW, I'd just use access(F_OK) instead of stat() it I don't care about > > > > > > I recommend _only_ using it when you require exactly the above real vs. > > > effective id behaviour. > > > > Does this distinction have any effect when doing F_OK? > > Actually, the documentation I've got says: > > "F_OK requests checking whether merely testing for the existence of the > file would be allowed (this depends on the permissions of the directories > in the path to the file, as given in path-name.)" > > So it shouldn't complain about a filename which you're allowed to try to > stat, even if there's nothing there. And it would depend on the privs of > the wrong user in looking at the path. The documentation I've got says: "R_OK, W_OK and X_OK request checking whether the file exists and has read, write and execute permissions, respectively. F_OK just requests checking for the existence of the file." And IEEE1003.1 agrees: http://www.opengroup.org/onlinepubs/009695399/functions/access.html -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor ``` ## Russell King, 2005-04-17 20:58 Subject: Re: [4/5] Add option for hardlinkable cache of extracted blobs Message-ID: <20050417215854.H13233@flint.arm.linux.org.uk> URL: https://gitlist.dev/e/20050417215854.H13233%40flint.arm.linux.org.uk In-Reply-To: ``` On Sun, Apr 17, 2005 at 04:03:46PM -0400, Daniel Barkalow wrote: > Actually, the documentation I've got says: > > "F_OK requests checking whether merely testing for the existence of the > file would be allowed (this depends on the permissions of the directories > in the path to the file, as given in path-name.)" > > So it shouldn't complain about a filename which you're allowed to try to > stat, even if there's nothing there. And it would depend on the privs of > the wrong user in looking at the path. Isn't it the case that with selinux, various objects may be hidden depending on their accessibility? I wonder if this has an effect here. (or what about any other security model?) -- Russell King ``` ## Linus Torvalds, 2005-04-17 22:10 Subject: First ever real kernel git merge! Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.58.0504171455070.7211%40ppc970.osdl.org In-Reply-To: <20050417215854.H13233@flint.arm.linux.org.uk> ``` It may not be pretty, but it seems to have worked fine! Here's my history log (with intermediate checking removed - I was being pretty anal ;): rsync -avz --ignore-existing master.kernel.org:/home/rmk/linux-2.6-rmk.git/ .git/ rsync -avz --ignore-existing master.kernel.org:/home/rmk/linux-2.6-rmk.git/HEAD .git/MERGE-HEAD merge-base $(cat .git/HEAD) $(cat .git/MERGE-HEAD) for i in e7905b2f22eb5d5308c9122b9c06c2d02473dd4f $(cat .git/HEAD) $(cat .git/MERGE-HEAD); do cat-file commit $i | head -1; done read-tree -m cf9fd295d3048cd84c65d5e1a5a6b606bf4fddc6 9c78e08d12ae8189f3bd5e03accc39e3f08e45c9 a43c4447b2edc9fb01a6369f10c1165de4494c88 write-tree commit-tree 7792a93eddb3f9b8e3115daab8adb3030f258ce6 -p $(cat .git/HEAD) -p $(cat .git/MERGE-HEAD) echo 5fa17ec1c56589476c7c6a2712b10c81b3d5f85a > .git/HEAD fsck-cache --unreachable 5fa17ec1c56589476c7c6a2712b10c81b3d5f85a which looks really messy, because I really wanted to do each step slowly by hand, so those magic revision numbers are just cut-and-pasted from the results that all the previous stages had printed out. NOTE! As expected, this merge had absolutely zero file-level clashes, which is why I could just do the "read-tree -m" followed by a write-tree. But it's a real merge: I had some extra commits in my tree that were not in Russell's tree, and obviously vice versa. Also note! The end result is not actually written back to the corrent working directory, so to see what the merge result actually is, there's another final phase: read-tree 7792a93eddb3f9b8e3115daab8adb3030f258ce6 update-cache --refresh checkout-cache -f -a which just updates the current working directory to the results. I'm _not_ caring about old dirty state for now - the theory was to get this thing working first, and worry about making it nice to use later. A second note: a real "merge" thing should notice that if the "merge-base" output ends up being one of the inputs (it one side is a strict subset of the other side), then the merge itself should never be done, and the script should just update directly to which-ever is non-common HEAD. But as far as I can tell, this really did work out correctly and 100% according to plan. As a result, if you update to my current tree, the top-of-tree commit should be: cat-file commit $(cat .git/HEAD) tree 7792a93eddb3f9b8e3115daab8adb3030f258ce6 parent 8173055926cdb8534fbaed517a792bd45aed8377 parent df4449813c900973841d0fa5a9e9bc7186956e1e author Linus Torvalds 1113774444 -0700 committer Linus Torvalds 1113774444 -0700 Merge with master.kernel.org:/home/rmk/linux-2.6-rmk.git - ARM changes First ever true git merge. Let's see if it actually works. Yehaa! It did take basically zero time, btw. Except for my bunbling about, and the first "rsync the objects from rmk's directory" part (which wasn't horrible, it just wasn't instantaneous like the other phases). Btw, to see the output, you really want to have a "git log" that sorts by date. I had an old "gitlog.sh" that did the old recursive thing, and while it shows the right thing, the ordering ended up making it be very non-obvious that rmk's changes had been added recently, since they ended up being at the very bottom. Linus ``` ## Paul Jackson, 2005-04-18 01:20 Subject: Re: [4/5] Add option for hardlinkable cache of extracted blobs Message-ID: <20050417182024.673605fa.pj@sgi.com> URL: https://gitlist.dev/e/20050417182024.673605fa.pj%40sgi.com In-Reply-To: <20050417195935.GI1461@pasky.ji.cz> ``` Petr wrote: > Does this distinction have any effect when doing F_OK? Well, yeah. If only one of real or effective id's could traverse the path (execute perm on directories), then you'd get the wrong answer. -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson 1.650.933.1373, 1.925.600.0401 ``` ## Paul Jackson, 2005-04-18 01:24 Subject: Re: [4/5] Add option for hardlinkable cache of extracted blobs Message-ID: <20050417182422.06dd7379.pj@sgi.com> URL: https://gitlist.dev/e/20050417182422.06dd7379.pj%40sgi.com In-Reply-To: ``` > So it shouldn't complain about a filename which you're allowed to try to > stat, even if there's nothing there. I'm not sure what 'nothing there' means to you. To me, it means 'no file there', so no you would not be allowed to stat it - and should fail ENOENT. > And it would depend on the privs of > the wrong user in looking at the path. Yup. -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson 1.650.933.1373, 1.925.600.0401 ``` ## Paul Jackson, 2005-04-18 01:35 Subject: Re: [4/5] Add option for hardlinkable cache of extracted blobs Message-ID: <20050417183508.15beb1fd.pj@sgi.com> URL: https://gitlist.dev/e/20050417183508.15beb1fd.pj%40sgi.com In-Reply-To: <20050417201856.GJ1461@pasky.ji.cz> ``` Petr wrote: > The documentation I've got says: > > "R_OK, W_OK and X_OK request checking whether the file exists and has > read, write and execute permissions, respectively. F_OK just requests > checking for the existence of the file." You don't exactly say it, but I'm guessing that you think that this documentation is stating that F_OK checks for the existance of the file _regardless_ of path access permissions. No so. Write your own little test program, and/or read the kernel source. Even if the file exists, if its directory entry is not accessible to the _real_ uid/gid, access F_OK will fail. If the problem is a lack of seach permissions on some directory in the path, the errno will be EACCES. -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson 1.650.933.1373, 1.925.600.0401 ``` ## Petr Baudis, 2005-04-18 01:48 Subject: Re: [4/5] Add option for hardlinkable cache of extracted blobs Message-ID: <20050418014858.GI1461@pasky.ji.cz> URL: https://gitlist.dev/e/20050418014858.GI1461%40pasky.ji.cz In-Reply-To: <20050417183508.15beb1fd.pj@sgi.com> ``` Dear diary, on Mon, Apr 18, 2005 at 03:35:08AM CEST, I got a letter where Paul Jackson told me that... > Petr wrote: > > The documentation I've got says: > > > > "R_OK, W_OK and X_OK request checking whether the file exists and has > > read, write and execute permissions, respectively. F_OK just requests > > checking for the existence of the file." > > You don't exactly say it, but I'm guessing that you think that this > documentation is stating that F_OK checks for the existance of the file > _regardless_ of path access permissions. > > No so. Write your own little test program, and/or read the kernel source. > > Even if the file exists, if its directory entry is not accessible to the > _real_ uid/gid, access F_OK will fail. If the problem is a lack of > seach permissions on some directory in the path, the errno will be > EACCES. Ok, I stand corrected; and when giving the access(2) manual page a second look, it could imply that too. It has some room for more crystal-clearness, though. ;-) Thanks, -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor ``` ## Paul Jackson, 2005-04-18 04:49 Subject: Re: [4/5] Add option for hardlinkable cache of extracted blobs Message-ID: <20050417214903.572a8a38.pj@sgi.com> URL: https://gitlist.dev/e/20050417214903.572a8a38.pj%40sgi.com In-Reply-To: <20050418014858.GI1461@pasky.ji.cz> ``` Pasky wrote: > It has some room for more > crystal-clearness, though. ;-) True indeed ;). -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson 1.650.933.1373, 1.925.600.0401 ```