Mail Archives: djgpp-workers/2002/06/26/11:18:43
My university exams have taken all my time in past few weeks, and now
I'm making my ways through e-mail backlog (slowly). I'm sorry if I
tell what others have already said, but anyways:
> (I wasn't around during the development, and haven't read the back
> discussions on this, so forgive me if this has all been covered...
> Why wasn't something like windows .lnk format chosen?
I've looked into this and discussed in this list. I don't remember the
exact outcome, but there are several problems: since symlink file won't
have any standard extension like .lnk, it would be impossible to tell
if a file is a symlink without opening it - a quite slow operation.
Current symlink implementation checks file size first (it should be
510 bytes), it catches 99% of non symlink files.
> Why remove the
> old EXE stubing type symlink - how to run these from command prompt?
I was thinking about creating new utility 'linkexe' which would be
based on code from pre-symlink symlink() implementation. Sadly, I
never got around implementing this.
> Some sort of documentation on symlinks?)
I was thinking about that too. However, I was very unsure about what
should I document. I was using Single UNIX Specification v2 for
API reference, so documenting that didn't seem necessarry. File format
is very simple and obvious. Maybe I should document which functions
support symlinks, which do not, and why?.. Maybe actual symlink
resolution algorithm?..
> Why? Because of non-DJGPP tool chain support I would suspect we would
> want to minimize symlink use to portability/testing support.
Sorry I don't understand. Could you be more specific please?
Laurynas
- Raw text -