Re: [Mingw-users] stubify?

[LRN <lrn1986@xxxxxxxxx>]

On 09.03.2010 1:43, Keith Marshall wrote:
> On Sunday 07 March 2010 13:22:44 Vincent Richomme wrote:
>   
>>>>>>> So finally what do you propose? Do nothing?
>>>>>>>               
>>>>>> You can write an equivalent of ln.exe that uses junction and
>>>>>> hardlink API to emulate symlinks and that accepts arguments
>>>>>> in correct order.
>>>>>>             
>>>> So can *you*.
>>>>         
>>> That is exactly what i did. Well, not exactly, but close (see
>>> the attachment).
>>>       
>> Great I was disassembling junction.exe and I even didn't know
>> FSCTL_XXXXX_REPARSE_POINT was officially part of SDK.
>>     
>
>
>> I suppose the next step would be to teach other part of msys how
>> to handle junctions, ...
>>     
> Well, if you can't teach `ln -s' to create them, *without* relying on 
> an unacceptable Microsoft SDK, (with its insidious EULA), to generate 
> your implementation, it's arguable if it's worth any further effort; 
> OTOH, if w32api already has sufficient capability...
>   
libntlink is 100% w32api, AFAIK, it does not need MS SDK.
>> for instance ls should be able to display them. 
>>     
> Do you mean to identify them, as a real Unix `ls' would identify 
> symbolic links?  Yes, that much would be necessary, as would giving 
> `rm' the capability to destroy them.  Beyond that, they should be 
> transparent to everything else.
>
>   
There is a comment in the code regarding unlink(). Basically, unlink()
can't know whether a hardlink was intended to be a poor man's symlink or
a real hardlink, and can't decide what (and when) to remove (especially
because 'target' of that 'symlink' is not stored anywhere). That is,
this will only work when application/script knows in advance which files
should be symlinked and to where, and does not need to rely on any
tools/APIs to obtain that information.

It could be possible to store that information separately in special
files (basically the same thing as cygwin's
shortcuts-instead-of-symlinks), or maybe within files themselves (NTFS
does provide some kind of per-file extra information storage structures,
but it is incompatible with some things), but that does not strike me
immediately as a good idea.

Even better approach is to write a filesystem extension driver that adds
symlink support to NTFS...but that is outside of my extremely limited
expertise (and kinda off-topic on this list).

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
MinGW-users mailing list
MinGW-users@xxxxxxxxxxxxxxxxxxxxx

This list observes the Etiquette found at 
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users