The following reply was made to PR bin/166056; it has been noted by GNATS.
From: Matthew Story <matthewst...@gmail.com>
To: freebsd-gnats-sub...@freebsd.org
Cc:
Subject: Re: bin/166056: [patch][bin] find fails with .: permission denied,
even when using absolute paths
Date: Wed, 14 Mar 2012 03:06:48 -0400
--20cf307ca01a78e21704bb2e9e78
Content-Type: multipart/alternative; boundary=20cf307ca01a78e21204bb2e9e76
--20cf307ca01a78e21204bb2e9e76
Content-Type: text/plain; charset=ISO-8859-1
On Tue, Mar 13, 2012 at 3:19 PM, Matthew Story <matthewst...@gmail.com>wrote:
> On Tue, Mar 13, 2012 at 3:08 PM, Matthew Story <matthewst...@gmail.com>wrote:
>
>> >Fix:
>> apply patch (patch was made against -CURRENT). patch will warn if it
>> cannot open ".", and set the FTL_NOCHDIR flag before proceeding, below
>> cases demonstrate functionality with&without the -exec flag
>>
>
> Embarrassingly enough, my patch breaks -execdir ... I will follow-up with
> a correction that doesn't break -execdir. Apologies for not being more
> thorough in my testing.
>
I have resolved the -execdir issue with my patch, and also resolved an
issue with -execdir not functioning properly with the -L option, as
FTS_LOGICAL sets FTS_NOCHDIR during fts_open(3):
from: libc/gen/fts.c
145 /* Logical walks turn on NOCHDIR; symbolic links are too hard. */
146 if (ISSET(FTS_LOGICAL))
147 SET(FTS_NOCHDIR);
It also sets FTS_NOCHDIR if it cannot open "." O_RDONLY. the man-page for
fts is silent on these two issues, I'll file a separate PR to document that.
There also seems to be an issue with find -execdir ... {} + wherein it
executes with cwd of the last entry (if plan->e_ppos is maxed out), or with
wd of the find process (if called by finish_execplus), my expectation for
this behavior would be to execute with arguments grouped by parent
directory. I preserved the existing behavior, as it is not as trivial as
fixing the -L behavior ... I will open another PR for this behavior.
new patch attached, viewable via http here:
http://axe0.blackskyresearch.net/patches/matt/find.no_dotfd.patch.txt
--
regards,
matt
--20cf307ca01a78e21204bb2e9e76
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Tue, Mar 13, 2012 at 3:19 PM, Matthew Story <span dir=3D"ltr"><<a hre=
f=3D"mailto:matthewst...@gmail.com";>matthewst...@gmail.com</a>></span> w=
rote:<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=3D"im">On Tue, Mar 13, 2012 at 3:08 PM, Matthew Story <span dir=
=3D"ltr"><<a href=3D"mailto:matthewst...@gmail.com"; target=3D"_blank">ma=
tthewst...@gmail.com</a>></span> wrote:</div><div class=3D"gmail_quote">=
<div class=3D"im">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
>Fix:<br>
apply patch (patch was made against -CURRENT). =A0patch will warn if it can=
not open ".", and set the FTL_NOCHDIR flag before proceeding, bel=
ow cases demonstrate functionality with&without the -exec flag<br></blo=
ckquote>
<div><br></div></div><div>Embarrassingly enough, my patch breaks -execdir .=
.. I will follow-up with a correction that doesn't break -execdir. =A0A=
pologies for not being more thorough in my testing.</div></div></blockquote=
>
<div><br></div><div>I have resolved the -execdir issue with my patch, and a=
lso resolved an issue with -execdir not functioning properly with the -L op=
tion, as FTS_LOGICAL sets FTS_NOCHDIR during fts_open(3):</div><div><br>
</div><div>from: libc/gen/fts.c</div><div>=A0145 =A0 =A0 /* Logical walks t=
urn on NOCHDIR; symbolic links are too hard. */</div><div>=A0146 =A0 =A0 if=
(ISSET(FTS_LOGICAL))</div><div>=A0147 =A0 =A0 =A0 =A0 SET(FTS_NOCHDIR);</d=
iv><div><br></div>
<div>It also sets FTS_NOCHDIR if it cannot open "." O_RDONLY. =A0=
the man-page for fts is silent on these two issues, I'll file a separat=
e PR to document that.</div><div><br></div><div>There also seems to be an i=
ssue with find -execdir ... {} + wherein it executes with cwd of the last e=
ntry (if plan->e_ppos is maxed out), or with wd of the find process (if =
called by finish_execplus), my expectation for this behavior would be to ex=
ecute with arguments grouped by parent directory. =A0I preserved the existi=
ng behavior, as it is not as trivial as fixing the -L behavior ... I will o=
pen another PR for this behavior.</div>
<div><br></div><div>new patch attached, viewable via http here:</div><div><=
br></div><div><a href=3D"http://axe0.blackskyresearch.net/patches/matt/find=
.no_dotfd.patch.txt">http://axe0.blackskyresearch.net/patches/matt/find.no_=
dotfd.patch.txt</a><br>
</div></div><br><br clear=3D"all"><div><br></div>-- <br>regards,<br>matt<br=
>
--20cf307ca01a78e21204bb2e9e76--
--20cf307ca01a78e21704bb2e9e78
Content-Type: text/plain; charset=US-ASCII; name="find.no_dotfd.patch.txt"
Content-Disposition: attachment; filename="find.no_dotfd.patch.txt"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_gzs0yp900
SW5kZXg6IGZ1bmN0aW9uLmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gZnVuY3Rpb24uYwkocmV2aXNpb24gMjMy
OTUwKQorKysgZnVuY3Rpb24uYwkod29ya2luZyBjb3B5KQpAQCAtNTAsNiArNTAsNyBAQAogI2lu
Y2x1ZGUgPGRpcmVudC5oPgogI2luY2x1ZGUgPGVyci5oPgogI2luY2x1ZGUgPGVycm5vLmg+Cisj
aW5jbHVkZSA8ZmNudGwuaD4KICNpbmNsdWRlIDxmbm1hdGNoLmg+CiAjaW5jbHVkZSA8ZnRzLmg+
CiAjaW5jbHVkZSA8Z3JwLmg+CkBAIC01OTUsNyArNTk2LDcgQEAKIGludAogZl9leGVjKFBMQU4g
KnBsYW4sIEZUU0VOVCAqZW50cnkpCiB7Ci0JaW50IGNudDsKKwlpbnQgY250LCBwYXRoX2ZkOwog
CXBpZF90IHBpZDsKIAlpbnQgc3RhdHVzOwogCWNoYXIgKmZpbGU7CkBAIC02NDQsOSArNjQ1LDMx
IEBACiAJCS8qIE5PVFJFQUNIRUQgKi8KIAljYXNlIDA6CiAJCS8qIGNoYW5nZSBkaXIgYmFjayBm
cm9tIHdoZXJlIHdlIHN0YXJ0ZWQgKi8KLQkJaWYgKCEocGxhbi0+ZmxhZ3MgJiBGX0VYRUNESVIp
ICYmIGZjaGRpcihkb3RmZCkpIHsKLQkJCXdhcm4oImNoZGlyIik7CisJCWlmICghKHBsYW4tPmZs
YWdzICYgRl9FWEVDRElSKSAmJiBcCisJCSAgICAhKHRyZWUtPmZ0c19vcHRpb25zICYgRlRTX05P
Q0hESVIpICYmIFwKKwkJICAgIGZjaGRpcihkb3RmZCkpIHsKIAkJCV9leGl0KDEpOworCQkvKiAK
KwkJICogaWYgbm8gZW50cnksIHdlIGFyZSBmaW5pc2hpbmcuIHdpdGhvdXQgRl9OT0NIRElSIHRo
aXMgd291bGQKKwkJICogaGFwcGVuIHRvIGJlIGluIHB3ZCwgc28gZG9uJ3QgY2hkaXIuIFdlIHVz
ZSB0cmVlLT5mdHNfb3B0aW9ucworCQkgKiBpbnN0ZWFkIG9mIGZ0c29wdGlvbnMsIGFzIEZUU19M
T0dJQ0FMIHNldHMgRlRTX05PQ0hESVIgb24KKwkJICogZnRzX29wZW4oMykKKwkJICovCisJCX0g
ZWxzZSBpZiAoZW50cnkgIT0gTlVMTCAmJiBlbnRyeS0+ZnRzX2xldmVsID4gMCAmJiBcCisJCSAg
ICAocGxhbi0+ZmxhZ3MgJiBGX0VYRUNESVIpICYmIFwKKwkJICAgICh0cmVlLT5mdHNfb3B0aW9u
cyAmIEZUU19OT0NIRElSKSkgeworCQkJLyogCisJCQkgKiAiVHJ1bmNhdGUiIGJ5IE5VTCBhdCBu
YW1lIGJvdW5kYXJ5LCB3ZSBjYW5ub3QgdXNlCisJCQkgKiBlbnRyeS0+ZnRzX3BhcmVudCBoZXJl
IGFzIGl0IGlzIG5vdCByZWxpYWJseSBzZXQKKwkJCSAqIHVubGVzcyB3ZSBoYXZlIGNhbGxlZCBm
dHNfY2hpbGRyZW4oMyksIHdoaWNoIHdlIGhhdmUKKwkJCSAqIG5vdC4KKwkJCSAqLworCQkJZW50
cnktPmZ0c19wYXRoW2VudHJ5LT5mdHNfcGF0aGxlbiAtIGVudHJ5LT5mdHNfbmFtZWxlbl0gPSAn
XDAnOworCQkJaWYgKChwYXRoX2ZkID0gb3BlbihlbnRyeS0+ZnRzX3BhdGgsIE9fUkRPTkxZLCAw
KSkgPCAwIFwKKwkJCSAgICB8fCBmY2hkaXIocGF0aF9mZCkgfHwgY2xvc2UocGF0aF9mZCkpIHsK
KwkJCQl3YXJuKCJjaGRpciIpOworCQkJCV9leGl0KDEpOworCQkJfSAKIAkJfQogCQlleGVjdnAo
cGxhbi0+ZV9hcmd2WzBdLCBwbGFuLT5lX2FyZ3YpOwogCQl3YXJuKCIlcyIsIHBsYW4tPmVfYXJn
dlswXSk7CkluZGV4OiBmaW5kLmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gZmluZC5jCShyZXZpc2lvbiAyMzI5
NTApCisrKyBmaW5kLmMJKHdvcmtpbmcgY29weSkKQEAgLTE3OSw3ICsxNzksNyBAQAogCiAJdHJl
ZSA9IGZ0c19vcGVuKHBhdGhzLCBmdHNvcHRpb25zLCAoaXNzb3J0ID8gZmluZF9jb21wYXJlIDog
TlVMTCkpOwogCWlmICh0cmVlID09IE5VTEwpCi0JCWVycigxLCAiZnRzb3BlbiIpOworCQllcnIo
MSwgImZ0c19vcGVuIik7CiAKIAlmb3IgKHJ2YWwgPSAwOyAoZW50cnkgPSBmdHNfcmVhZCh0cmVl
KSkgIT0gTlVMTDspIHsKIAkJaWYgKG1heGRlcHRoICE9IC0xICYmIGVudHJ5LT5mdHNfbGV2ZWwg
Pj0gbWF4ZGVwdGgpIHsKSW5kZXg6IG1haW4uYwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBtYWluLmMJKHJldmlz
aW9uIDIzMjk1MCkKKysrIG1haW4uYwkod29ya2luZyBjb3B5KQpAQCAtNjMsNyArNjMsNyBAQAog
CiB0aW1lX3Qgbm93OwkJCS8qIHRpbWUgZmluZCB3YXMgcnVuICovCiBpbnQgZG90ZmQ7CQkJLyog
c3RhcnRpbmcgZGlyZWN0b3J5ICovCi1pbnQgZnRzb3B0aW9uczsJCQkvKiBvcHRpb25zIGZvciB0
aGUgZnRzb3BlbigzKSBjYWxsICovCitpbnQgZnRzb3B0aW9uczsJCQkvKiBvcHRpb25zIGZvciB0
aGUgZnRzX29wZW4oMykgY2FsbCAqLwogaW50IGlzZGVwcmVjYXRlZDsJCS8qIHVzaW5nIGRlcHJl
Y2F0ZWQgc3ludGF4ICovCiBpbnQgaXNkZXB0aDsJCQkvKiBkbyBkaXJlY3RvcmllcyBvbiBwb3N0
LW9yZGVyIHZpc2l0ICovCiBpbnQgaXNvdXRwdXQ7CQkJLyogdXNlciBzcGVjaWZpZWQgb3V0cHV0
IG9wZXJhdG9yICovCkBAIC0xNTAsOCArMTUwLDEwIEBACiAJCXVzYWdlKCk7CiAJKnAgPSBOVUxM
OwogCi0JaWYgKChkb3RmZCA9IG9wZW4oIi4iLCBPX1JET05MWSwgMCkpIDwgMCkKLQkJZXJyKDEs
ICIuIik7CisJaWYgKChkb3RmZCA9IG9wZW4oIi4iLCBPX1JET05MWSwgMCkpIDwgMCkgeworCQl3
YXJuKCIuIik7CisJCWZ0c29wdGlvbnMgfD0gRlRTX05PQ0hESVI7CisJfQogCiAJZXhpdChmaW5k
X2V4ZWN1dGUoZmluZF9mb3JtcGxhbihhcmd2KSwgc3RhcnQpKTsKIH0K
--20cf307ca01a78e21704bb2e9e78--
_______________________________________________
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
