[Bug 202192] [PATCH] x11-fm/thunar 1.6.11 change file permissions on sshfs mounted files/dirs

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202192

Guido Falsi <madpilot at FreeBSD.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|Open                        |Closed
         Resolution|---                         |Rejected

--- Comment #12 from Guido Falsi <madpilot at 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.
> 
> On access deny user will get error on apply, it much better than do not try
> 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 must
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 thing
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 false
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" resolution
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 developers.

-- 
You are receiving this mail because:
You are the assignee for the bug.