Re: [platform-vcm-dev] bugzilla 24724: permission bits

[Tom Tromey <tromey@xxxxxxxxxx>]

>>>>> "Michael" == Michael Valenta <Michael_Valenta@xxxxxxx> writes:

Michael> I will investigate the various options we have with the hope
Michael> of comming up with a solution for 2.1.

Ok.  I'm not positive but I think we'll be shipping based on 2.0.x.
That's fine; I'll just check in my fix locally and either help on or
wait for the full fix in 2.1.

Michael> 1) Apply your patch and provide support for other platforms
Michael> that either sets the bit or does nothing (for platforms that
Michael> don't have execute bits).

I only implemented the native code for Unix.  It should be very
portable among Unix variants in practice.

It would be trivial to implement native code that does what we do now,
i.e. nothing.  That code may be useful on Windows.

I have never used QNX.  I'm under the impression it is Unix-like, so
perhaps the Unix code would work there as well.

Are there other host platforms to worry about?

If you'd like me to upload the patch now, I can.  If not, it is no
trouble to upload it in the future if you later decide you want it.
I can attach it as a patch to the bugzilla PR.

Michael> 2) Investigate whether Platform Core would provide the
Michael> natives since it is conceivable that other plugins would want
Michael> to access/set the execute bit.

Yes, that makes sense.  Yesterday Keith pointed out to me that Eclipse
also loses the executable bit when importing a project into the
workspace.  I haven't looked at this yet (I barely know what it means
:-), but if the fix for it isn't in the cvs module then that would
strengthen the case for putting this functionality in the core.

Michael> 3) Use Runtime#exec to get/set the execute bit when
Michael> required. This would be a bit slower than 2 but should still
Michael> work.

I considered this but thought it was a bit ugly.  But I agree it is
viable, even easy: exec chmod to set the bit and parse the output of
`ls -l' (this is the ugly part :-) to read it.

Michael> I will investigate each of these options further and let you
Michael> know what the resutls are.

Thanks, I appreciate it.  As I mentioned, this bug is very important
to us.  Three of us on the development team independently ran into
this problem.

Tom