{"thread":{"id":"90","subject":"Re: [4/5] Add option for hardlinkable cache of extracted blobs","startedAt":"2005-04-17T19:59:35Z","lastAt":"2005-04-18T04:49:03Z","messageCount":10,"participants":["Petr Baudis","Daniel Barkalow","Russell King","Linus Torvalds","Paul Jackson"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"540","messageId":"20050417195935.GI1461@pasky.ji.cz","threadId":"90","inReplyTo":"20050417122517.4b12faea.pj@sgi.com","subject":"Re: [4/5] Add option for hardlinkable cache of extracted blobs","fromName":"Petr Baudis","fromEmail":"pasky@ucw.cz","sentAt":"2005-04-17T19:59:35Z","receivedAt":"2005-04-17T19:59:35Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Sun, Apr 17, 2005 at 09:25:17PM CEST, I got a letter\nwhere Paul Jackson told me that...\n> Petr wrote:\n> > BTW, I'd just use access(F_OK) instead of stat() it I don't care about\n> \n> I recommend _only_ using it when you require exactly the above real vs.\n> effective id behaviour.\n\nDoes this distinction have any effect when doing F_OK?\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nC++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor\n"},{"id":"542","messageId":"Pine.LNX.4.21.0504171600310.30848-100000@iabervon.org","threadId":"90","inReplyTo":"20050417195935.GI1461@pasky.ji.cz","subject":"Re: [4/5] Add option for hardlinkable cache of extracted blobs","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2005-04-17T20:03:46Z","receivedAt":"2005-04-17T20:03:46Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Sun, 17 Apr 2005, Petr Baudis wrote:\n\n> Dear diary, on Sun, Apr 17, 2005 at 09:25:17PM CEST, I got a letter\n> where Paul Jackson told me that...\n> > Petr wrote:\n> > > BTW, I'd just use access(F_OK) instead of stat() it I don't care about\n> > \n> > I recommend _only_ using it when you require exactly the above real vs.\n> > effective id behaviour.\n> \n> Does this distinction have any effect when doing F_OK?\n\nActually, the documentation I've got says:\n\n\"F_OK requests checking whether merely testing for the existence of the\n file would be allowed (this depends on the permissions of the directories\n in the path to the file, as given in path-name.)\"\n\nSo it shouldn't complain about a filename which you're allowed to try to\nstat, even if there's nothing there. And it would depend on the privs of\nthe wrong user in looking at the path.\n\n\t-Daniel\n*This .sig left intentionally blank*\n\n"},{"id":"538","messageId":"20050417201856.GJ1461@pasky.ji.cz","threadId":"90","inReplyTo":"Pine.LNX.4.21.0504171600310.30848-100000@iabervon.org","subject":"Re: [4/5] Add option for hardlinkable cache of extracted blobs","fromName":"Petr Baudis","fromEmail":"pasky@ucw.cz","sentAt":"2005-04-17T20:18:56Z","receivedAt":"2005-04-17T20:18:56Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Sun, Apr 17, 2005 at 10:03:46PM CEST, I got a letter\nwhere Daniel Barkalow told me that...\n> On Sun, 17 Apr 2005, Petr Baudis wrote:\n> \n> > Dear diary, on Sun, Apr 17, 2005 at 09:25:17PM CEST, I got a letter\n> > where Paul Jackson told me that...\n> > > Petr wrote:\n> > > > BTW, I'd just use access(F_OK) instead of stat() it I don't care about\n> > > \n> > > I recommend _only_ using it when you require exactly the above real vs.\n> > > effective id behaviour.\n> > \n> > Does this distinction have any effect when doing F_OK?\n> \n> Actually, the documentation I've got says:\n> \n> \"F_OK requests checking whether merely testing for the existence of the\n> file would be allowed (this depends on the permissions of the directories\n> in the path to the file, as given in path-name.)\"\n> \n> So it shouldn't complain about a filename which you're allowed to try to\n> stat, even if there's nothing there. And it would depend on the privs of\n> the wrong user in looking at the path.\n\nThe documentation I've got says:\n\n\"R_OK, W_OK and X_OK request checking whether the file exists and has\n read, write and execute permissions, respectively. F_OK just requests\n checking for the existence of the file.\"\n\nAnd IEEE1003.1 agrees:\nhttp://www.opengroup.org/onlinepubs/009695399/functions/access.html\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nC++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor\n"},{"id":"543","messageId":"20050417215854.H13233@flint.arm.linux.org.uk","threadId":"90","inReplyTo":"Pine.LNX.4.21.0504171600310.30848-100000@iabervon.org","subject":"Re: [4/5] Add option for hardlinkable cache of extracted blobs","fromName":"Russell King","fromEmail":"rmk@arm.linux.org.uk","sentAt":"2005-04-17T20:58:55Z","receivedAt":"2005-04-17T20:58:55Z","isPatch":false,"sender":{"key":"rmk@arm.linux.org.uk","avatar":null},"body":"On Sun, Apr 17, 2005 at 04:03:46PM -0400, Daniel Barkalow wrote:\n> Actually, the documentation I've got says:\n> \n> \"F_OK requests checking whether merely testing for the existence of the\n> file would be allowed (this depends on the permissions of the directories\n> in the path to the file, as given in path-name.)\"\n> \n> So it shouldn't complain about a filename which you're allowed to try to\n> stat, even if there's nothing there. And it would depend on the privs of\n> the wrong user in looking at the path.\n\nIsn't it the case that with selinux, various objects may be hidden\ndepending on their accessibility? I wonder if this has an effect\nhere.\n\n(or what about any other security model?)\n\n-- \nRussell King\n\n"},{"id":"549","messageId":"Pine.LNX.4.58.0504171455070.7211@ppc970.osdl.org","threadId":"90","inReplyTo":"20050417215854.H13233@flint.arm.linux.org.uk","subject":"First ever real kernel git merge!","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-04-17T22:10:25Z","receivedAt":"2005-04-17T22:10:25Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\nIt may not be pretty, but it seems to have worked fine!\n\nHere's my history log (with intermediate checking removed - I was being\npretty anal ;):\n\n\trsync -avz --ignore-existing master.kernel.org:/home/rmk/linux-2.6-rmk.git/ .git/\n\trsync -avz --ignore-existing master.kernel.org:/home/rmk/linux-2.6-rmk.git/HEAD .git/MERGE-HEAD\n\tmerge-base $(cat .git/HEAD) $(cat .git/MERGE-HEAD)\n\tfor i in e7905b2f22eb5d5308c9122b9c06c2d02473dd4f $(cat .git/HEAD) $(cat .git/MERGE-HEAD); do cat-file commit $i | head -1; done\n\tread-tree -m cf9fd295d3048cd84c65d5e1a5a6b606bf4fddc6 9c78e08d12ae8189f3bd5e03accc39e3f08e45c9 a43c4447b2edc9fb01a6369f10c1165de4494c88\n\twrite-tree \n\tcommit-tree 7792a93eddb3f9b8e3115daab8adb3030f258ce6 -p $(cat .git/HEAD) -p $(cat .git/MERGE-HEAD)\n\techo 5fa17ec1c56589476c7c6a2712b10c81b3d5f85a > .git/HEAD \n\tfsck-cache --unreachable 5fa17ec1c56589476c7c6a2712b10c81b3d5f85a\n\nwhich looks really messy, because I really wanted to do each step slowly \nby hand, so those magic revision numbers are just cut-and-pasted from the \nresults that all the previous stages had printed out.\n\nNOTE! As expected, this merge had absolutely zero file-level clashes,\nwhich is why I could just do the \"read-tree -m\" followed by a write-tree. \nBut it's a real merge: I had some extra commits in my tree that were not\nin Russell's tree, and obviously vice versa.\n\nAlso note! The end result is not actually written back to the corrent \nworking directory, so to see what the merge result actually is, there's \nanother final phase:\n\n\tread-tree 7792a93eddb3f9b8e3115daab8adb3030f258ce6\n\tupdate-cache --refresh\n\tcheckout-cache -f -a\n\nwhich just updates the current working directory to the results. I'm _not_\ncaring about old dirty state for now - the theory was to get this thing\nworking first, and worry about making it nice to use later.\n\nA second note: a real \"merge\" thing should notice that if the \"merge-base\" \noutput ends up being one of the inputs (it one side is a strict subset of\nthe other side), then the merge itself should never be done, and the\nscript should just update directly to which-ever is non-common HEAD.\n\nBut as far as I can tell, this really did work out correctly and 100% \naccording to plan. As a result, if you update to my current tree, the \ntop-of-tree commit should be:\n\n\tcat-file commit $(cat .git/HEAD)\n\n\ttree 7792a93eddb3f9b8e3115daab8adb3030f258ce6\n\tparent 8173055926cdb8534fbaed517a792bd45aed8377\n\tparent df4449813c900973841d0fa5a9e9bc7186956e1e\n\tauthor Linus Torvalds 1113774444 -0700\n\tcommitter Linus Torvalds 1113774444 -0700\n\n\tMerge with master.kernel.org:/home/rmk/linux-2.6-rmk.git - ARM changes\n\n\tFirst ever true git merge. Let's see if it actually works.\n\nYehaa! It did take basically zero time, btw. Except for my bunbling about,\nand the first \"rsync the objects from rmk's directory\" part (which wasn't\nhorrible, it just wasn't instantaneous like the other phases).\n\nBtw, to see the output, you really want to have a \"git log\" that sorts by \ndate. I had an old \"gitlog.sh\" that did the old recursive thing, and while \nit shows the right thing, the ordering ended up making it be very \nnon-obvious that rmk's changes had been added recently, since they ended \nup being at the very bottom.\n\n\t\t\tLinus\n"},{"id":"593","messageId":"20050417182024.673605fa.pj@sgi.com","threadId":"90","inReplyTo":"20050417195935.GI1461@pasky.ji.cz","subject":"Re: [4/5] Add option for hardlinkable cache of extracted blobs","fromName":"Paul Jackson","fromEmail":"pj@sgi.com","sentAt":"2005-04-18T01:20:24Z","receivedAt":"2005-04-18T01:20:24Z","isPatch":false,"sender":{"key":"pj@sgi.com","avatar":null},"body":"Petr wrote:\n> Does this distinction have any effect when doing F_OK?\n\nWell, yeah. If only one of real or effective id's could traverse the\npath (execute perm on directories), then you'd get the wrong answer.\n\n-- \n I won't rest till it's the best ...\n Programmer, Linux Scalability\n Paul Jackson 1.650.933.1373, 1.925.600.0401\n"},{"id":"594","messageId":"20050417182422.06dd7379.pj@sgi.com","threadId":"90","inReplyTo":"Pine.LNX.4.21.0504171600310.30848-100000@iabervon.org","subject":"Re: [4/5] Add option for hardlinkable cache of extracted blobs","fromName":"Paul Jackson","fromEmail":"pj@sgi.com","sentAt":"2005-04-18T01:24:22Z","receivedAt":"2005-04-18T01:24:22Z","isPatch":false,"sender":{"key":"pj@sgi.com","avatar":null},"body":"> So it shouldn't complain about a filename which you're allowed to try to\n> stat, even if there's nothing there.\n\nI'm not sure what 'nothing there' means to you.\n\nTo me, it means 'no file there', so no you would not be allowed\nto stat it - and should fail ENOENT.\n\n> And it would depend on the privs of\n> the wrong user in looking at the path.\n\nYup.\n\n-- \n I won't rest till it's the best ...\n Programmer, Linux Scalability\n Paul Jackson 1.650.933.1373, 1.925.600.0401\n"},{"id":"596","messageId":"20050417183508.15beb1fd.pj@sgi.com","threadId":"90","inReplyTo":"20050417201856.GJ1461@pasky.ji.cz","subject":"Re: [4/5] Add option for hardlinkable cache of extracted blobs","fromName":"Paul Jackson","fromEmail":"pj@sgi.com","sentAt":"2005-04-18T01:35:08Z","receivedAt":"2005-04-18T01:35:08Z","isPatch":false,"sender":{"key":"pj@sgi.com","avatar":null},"body":"Petr wrote:\n> The documentation I've got says:\n> \n> \"R_OK, W_OK and X_OK request checking whether the file exists and has\n> read, write and execute permissions, respectively. F_OK just requests\n> checking for the existence of the file.\"\n\nYou don't exactly say it, but I'm guessing that you think that this\ndocumentation is stating that F_OK checks for the existance of the file\n_regardless_ of path access permissions.\n\nNo so. Write your own little test program, and/or read the kernel source.\n\nEven if the file exists, if its directory entry is not accessible to the\n_real_ uid/gid, access F_OK will fail. If the problem is a lack of\nseach permissions on some directory in the path, the errno will be\nEACCES.\n\n-- \n I won't rest till it's the best ...\n Programmer, Linux Scalability\n Paul Jackson 1.650.933.1373, 1.925.600.0401\n"},{"id":"598","messageId":"20050418014858.GI1461@pasky.ji.cz","threadId":"90","inReplyTo":"20050417183508.15beb1fd.pj@sgi.com","subject":"Re: [4/5] Add option for hardlinkable cache of extracted blobs","fromName":"Petr Baudis","fromEmail":"pasky@ucw.cz","sentAt":"2005-04-18T01:48:58Z","receivedAt":"2005-04-18T01:48:58Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Mon, Apr 18, 2005 at 03:35:08AM CEST, I got a letter\nwhere Paul Jackson told me that...\n> Petr wrote:\n> > The documentation I've got says:\n> > \n> > \"R_OK, W_OK and X_OK request checking whether the file exists and has\n> > read, write and execute permissions, respectively. F_OK just requests\n> > checking for the existence of the file.\"\n> \n> You don't exactly say it, but I'm guessing that you think that this\n> documentation is stating that F_OK checks for the existance of the file\n> _regardless_ of path access permissions.\n> \n> No so. Write your own little test program, and/or read the kernel source.\n> \n> Even if the file exists, if its directory entry is not accessible to the\n> _real_ uid/gid, access F_OK will fail. If the problem is a lack of\n> seach permissions on some directory in the path, the errno will be\n> EACCES.\n\nOk, I stand corrected; and when giving the access(2) manual page a\nsecond look, it could imply that too. It has some room for more\ncrystal-clearness, though. ;-)\n\nThanks,\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nC++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor\n"},{"id":"627","messageId":"20050417214903.572a8a38.pj@sgi.com","threadId":"90","inReplyTo":"20050418014858.GI1461@pasky.ji.cz","subject":"Re: [4/5] Add option for hardlinkable cache of extracted blobs","fromName":"Paul Jackson","fromEmail":"pj@sgi.com","sentAt":"2005-04-18T04:49:03Z","receivedAt":"2005-04-18T04:49:03Z","isPatch":false,"sender":{"key":"pj@sgi.com","avatar":null},"body":"Pasky wrote:\n> It has some room for more\n> crystal-clearness, though. ;-)\n\nTrue indeed ;).\n\n-- \n I won't rest till it's the best ...\n Programmer, Linux Scalability\n Paul Jackson 1.650.933.1373, 1.925.600.0401\n"}]}