From: marcus AT bighorn DOT dr DOT lucent DOT com Subject: Re: Feedback needed on proposed cygwin feature 2 Dec 1997 13:49:20 -0800 Message-ID: <199712021608.JAA04416.cygnus.gnu-win32@chorus.dr.lucent.com> To: gnu-win32 AT cygnus DOT com Jason Zions 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 AT cygnus DOT com" with one line of text: "help".