Mail Archives: cygwin/2006/11/30/01:43:12
I'm not saying all the pieces of this puzzle are in place yet, but
supporting it could be done in a way as to minimize impact to
existing "dumb apps", and future "extended-attribute-aware apps".
I'm not suggesting anyone run off and implement this immediately, though
that could be done and compatibility could be retained, with the
code in place to add future compatibility being toggled by a value
in the environment (CYGWIN var seems appropriate place).
The value in the CYGWIN var, would something along the lines of
"extendedlinks".
Immediately, there would be no noticeable change, as that string would
default to being "not present".
Current problem, as I understand it is that current *nix apps wouldn't
see the extra windows fields, so if tar were to dump/restore, the
extra information would be lost.
I believe (please correct me if I'm incorrect), but this is already a
problem -- cygwin tar and cousins already cannot backup and restore
windows files with an expectation of success except in limited
circumstances. Failure cases, I believe (but may not be limited to):
1) dumping and restoring files containing ACLs. This one may be
possible through POSIX extensions, but since NT and Posix ACLs differ,
restored ACL's may not match the original ACL's.
2) NT streams. One can use a type of Extended Attribute known
as a "Stream" that is hidden from the normal user interface but
accessible by "filename:stream". From the MS website, they see
Extended attributes to hold:
*EA *
Extended attribute. An EA is viewed as an untyped name-value
pair that is defined by the user to describe extended
information about a file. Typical system uses are to store
the icon for an image, to indicate that the file is a symbolic
link, and so on.
There may be other examples, but the stream type "EA" seems exactly
what was intended to "really" store icons for short-cut images and
data to indicate the file is a symbolic link.
It seems cygwin could convert a Windows type "lnk", into a special
type of the shortcut name (cygwin compatible type), then using the
stream support (which might be made accessible to tar as a
"filename:stream" designator, that, when unpacked under cygwin, could
be restored to a bit-for-bit duplicate of the original Windows
symlink.
Please don't answer this with a "oh, that's nice, code submissions will
be greatfully appreciated and appropriately reviewed. I saw how that
worked for someone suggesting "utf8" support. I haven't read the
details -- all I know was he had something working for his setup, and
was shot down for, what I'm sure, technical reasons that sound very
good. But it's always easier to shoot things down than to create and
make things work (as I'm sure you'll agree from your own experience).
Telling someone with an idea to either put-up-the-code or "never mind"
seem just a way of ending discussions about future features
for anyone who isn't a cygwin-internal programmer (meaning, it's a
way to shoot down the majority of cygwin users who make suggestions).
The way to cinch that methodology is to show those who do submit code
all the reasons why their code (working in their system) wouldn't work
in the cygwin official source. (Hey, I'm not saying my stuff doesn't
smell at times in this area, either! ;^/ )
But the effect of such remarks is simple to beat users into
taking whatever is dished out [submission?], no longer having
much of a desire to fight such an uphill battle.
As I've been told before, and as I have seen others told, having cygwin
work with windows links could not be done. I'm assuming some people have
gifts in solving problems in, perhaps, non-standard ways, while others
may be expert at the internals of cygwin and interfacing them with NT.
Not everyone is identical and not everyone has identical talents.
Observably, it is often the case that people strong in one area are
not as strong in others (other than the occasional genius that
seems to be able to everything better than anyone else...but that's
exceedingly rare).
Linda W
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -