This is the mail archive of the cygwin@sourceware.cygnus.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Feedback needed on proposed cygwin feature


Jason Zions <jazz@softway.com> wrote:
>It strikes me that the best place for per-binary attributed like this
>would be in the binary itself. I don't know how closely cygwin's exec()
>looks at the program being exec'd; if it looks at the program header,
>there should be a way to squirrel the attributes away there someplace.

If there isn't anyplace in the file header that can be used to store this
info away in that doesn't upset NT/W95, or if it is costly to open the object
file whenever a program starts execution, perhaps it would be possible to
provide some global variables in the crt0.o module for controlling various
attributes.  The tool to set the attributes would have to go through the
name list to find the variables, then find the section to modify.  Shouldn't
be too bad, and the performance of the attribute setting program isn't
critical anyway, but it would require that the file not be fully stripped.

On the other hand, perhaps a data section could be defined that contains an
array of attribute flags, or even space for ASCII attribute names.  This
section (perhaps .cygwin_attributes) could be initially provided by the crt0.o
file, then a pointer to it is passed to the DLL on process startup.

Using an array of flags allows easy allowance for significant expansion, but at the cost of having a fixed structure (i.e. the first flag corresponds to the
force-binary attribute, the second flag...) while the ASCII attribute name
requires a "big enough" fixed size buffer be pre-allocated to hold the list
of attributes, and what happens when an attribute name is not recognized by
the DLL?  Of course, perhaps the attribute setting program could change the
section size, etc....

cgf replies to Jason:
> Also, in actuality, the binary does not know that it has been invoked via
> a symbolic link since this is a cygwin affectation.  If you have two
> files hard linked together you might actually *want* to have separate
> settings for them.

You might want separate settings in some cases, but you might also get very
confused by separate settings as well.  If this is supposed to be "Unix-like",
then it would be least surprising to attach the attribute to the file instead
of the name.

Other issues with using name:

The full path name must be unambiguously stored with the attribute and expanded
for execution.  Otherwise, some peculiar things may not work correctly, such
as invoking the program as "../bin/program", using a symbolic link to a
directory "symlinktobin/program", etc.  If the attributes are not consistently
found whenever a program is run, the program will have inconsistent behaviour.

If attributes are set for a program, then the program is moved to another
location or given another name, it looses the attributes.  Furthermore, if
a new program is created (perhaps months later) with the same name and
location, it will mysteriously gain the attributes.  These problems do apply
to symbolic links currently, so they aren't new, but they can be confusing
particularly since they may have subtle effects on the execution of the program
instead of a hard failure to follow a link.

marcus hall
Lucent Technologies
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]