Date: Wed, 29 Nov 2017 11:28:01 +0000 From: bugzilla-noreply@freebsd.org To: xfce@FreeBSD.org Subject: [Bug 202192] [PATCH] x11-fm/thunar 1.6.11 change file permissions on sshfs mounted files/dirs Message-ID: <bug-202192-28711-pgQ35tKnwZ@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-202192-28711@https.bugs.freebsd.org/bugzilla/> References: <bug-202192-28711@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D202192 Guido Falsi <madpilot@FreeBSD.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Open |Closed Resolution|--- |Rejected --- Comment #12 from Guido Falsi <madpilot@FreeBSD.org> --- (In reply to rozhuk.im from comment #10) > False positive - not problem, at least for me. > I dont care even if it always return true without any checks. >=20 > On access deny user will get error on apply, it much better than do not t= ry > chmod() because of false-negative. I agree that having that check return true would work for you, with your simplistic definition of "works". First of all consider that the ports tree is not yours, and all use cases m= ust be kept in consideration. You also must consider that the ports tree contains that, ported software. Original development must be done upstream. If the upstream does a stupid t= hing the port will also do a stupid thing. The only logical exception is when the stupid thing is caused by a specific FreeBSD difference from other OSes. In that case too at least trying to get a correct patch accepted upstream is a requirement. The upstream code shows that the xfce guys actually don't want to hit system call errors and that's the very reason why they apply such a check. Your patch is anyway definitely wrong and would give false positives and fa= lse negatives on UFS and ZFS, since write permissions are completely unrelated = to chmod usage. Returning true would be a clear breakage of upstream code. This patch is not acceptable and it looks like your use case is not catered= by upstream. So the software is "working as intended", you happen to disagree = with the intended way the upstream software should work. regarding comment 11, since you disagree on the "works as intended" resolut= ion I'll change it to a more arbitrary "rejected", so you will have one excuse = less to open this up again. I encourage you to push a correct solution with the upstream thunar develop= ers. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-202192-28711-pgQ35tKnwZ>