--- Comment #5 from Guido Falsi <> ---
(In reply to from comment #4)
> IMHO they dont try build without HAVE_GIO_UNIX: GDesktopAppInfo is part of
> gio and hey will get undefined struct/type compiler error.
> They patch does not work (without mine) - 100%.
> Upstream do many insane and crappy things, I dont want understand why :)

First of all a general clarification:

I can understand but keep in mind that ports are just that, portings.

The development should happen upstream and bugfixes should go there where there
are developers who know how the existing code works and also usually have
better ability to test changes.

This kind of changes which diverge from upstream tend to make maintain a port
difficult and could also cause regressions which end up being unjustly reported
upstream casting shadows on FreeBSD porting methods.

I think you understand divergence with upstream should be kept to a minimum.

So as a general rule I'm accepting such changes only if they are for very
important bugs and have good chance of being merged upstream, or are very
FreeBSD specific (which sometimes hinders upstream inclusion).

For the GIO part, how do I test in the ports tree with GIO disabled? The port
does not have such an option, so it looks like we don't cover this condition

> I replace
> effective_user_id == g_file_info_get_attribute_uint32 (file->info,
> to
> thunar_file_is_writable(file)
> All other logic not changed, just refactored to human understanding.
> You can use both checks via ||, like:
> return (effective_user_id == g_file_info_get_attribute_uint32 (file->info,
> G_FILE_ATTRIBUTE_UNIX_UID) || thunar_file_is_writable(file))
> May be in some cases there different access levels for file data and
> metadata and original code will return TRUE is user is file owner or root.
> I dont know what use cases this cover, probably none.
> My check is simple: if file writeable than we can write metadata.
> This is good for most cases.
> I dont know how to allow user write data and restrict write metadata in unix
> with chmod().

As I said while I hear and understand your explanation I have no explanation
about the existing code.

I'm not refusing your code, and have no specific objection about it.
I just need time to understand it properly.

In the while if you can get your code included upstream or at least reviewed by
an upstream developer that would greatly help this request.

> In my case sshfs mounted to me (simple user), by authorized on remote side
> as root.

Not sure I understand, you mean that you are a plain user on the local machine
but authenticated as root on the ssh mount on the remote one?

You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________ mailing list
To unsubscribe, send any mail to ""

Reply via email to