Re: Feedback needed on proposed cygwin feature

[Chris Faylor <cgf at bbc dot com>]

>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.
>
>Many "real Unix" systems do just this sort of thing; e.g. chatr in
>HP-UX, which is used to alter a.out attributes.
>
>Pro: 
>  a) attributes are *really* a part of the binary; symlinks and
>hardlinks all pointing to the same bits on the disk will behave the
>same, while name-based approaches may be inconsistent
>
>  b) makes it easier for attributes to work over network mounts (when
>filesystems can be mounted in different places)
>
>Con:
>  a) extracting the attributes from the binary may be slower
>
>  b) may be hard to find a "safe place" to stash the bits

Actually, Geoffrey had already mentioned this scenario in private email.
I should have mentioned it in my original message.

It is certainly doable using extended attributes on Windows NT.
Extended attributes are not an option for Windows 95, however.  I think
that it would end up being slightly slower than using the registry since
the registry options stand a better chance of being cached than a file's
attributes.

I agree that it probably would be possible to modify the binary header.
I don't have the expertise to do so, however.  If anyone else can volunteer
a way to store arbitrary data in PE binary I'll be happy to incorporate it.

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.

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