[prev in list] [next in list] [prev in thread] [next in thread]
List: mingw-notify
Subject: MinGW-notify Digest, Vol 51, Issue 7
From: mingw-notify-request () lists ! sourceforge ! net
Date: 2010-08-18 13:30:07
Message-ID: mailman.879614.1282138207.4911.mingw-notify () lists ! sourceforge ! net
[Download RAW message or body]
Send MinGW-notify mailing list submissions to
mingw-notify@lists.sourceforge.net
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.sourceforge.net/lists/listinfo/mingw-notify
or, via email, send a message with subject or body 'help' to
mingw-notify-request@lists.sourceforge.net
You can reach the person managing the list at
mingw-notify-owner@lists.sourceforge.net
When replying, please edit your Subject line so it is more specific
than "Re: Contents of MinGW-notify digest..."
This list is used to send updates of submitted patches, bug reports and file \
releases. You are discouraged from posting to this list. If you wish to unsubscribe \
you can do so at https://lists.sourceforge.net/lists/listinfo/mingw-notify.
Today's Topics:
1. [ mingw-Patches-3047566 ] Add CreateSymbolicLink declaration
(SF/projects/mingw notification list)
2. [ mingw-Patches-3047566 ] Add CreateSymbolicLink declaration
(SF/projects/mingw notification list)
3. [ mingw-Patches-3047571 ] Fix order of msys_symlink arguments
(SF/projects/mingw notification list)
4. [ mingw-Patches-3047571 ] Fix order of msys_symlink arguments
(SF/projects/mingw notification list)
5. [ mingw-Patches-3047571 ] Fix order of msys_symlink arguments
(SF/projects/mingw notification list)
6. [ mingw-Patches-3046195 ] Native symlinks
(SF/projects/mingw notification list)
----------------------------------------------------------------------
Message: 1
Date: Wed, 18 Aug 2010 10:50:59 +0000
From: SF/projects/mingw notification list
<mingw-notify@lists.sourceforge.net>
Subject: [MinGW-notify] [ mingw-Patches-3047566 ] Add
CreateSymbolicLink declaration
To: noreply@sourceforge.net
Message-ID: <E1OlgEV-00012U-Dj@sfs-web-9.v29.ch3.sourceforge.com>
Content-Type: text/plain; charset="UTF-8"
Patches item #3047566, was opened at 2010-08-18 08:40
Message generated for change (Comment added) made by keithmarshall
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=302435&aid=3047566&group_id=2435
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: w32api
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Ladislav Michl (ladis)
> Assigned to: Chris Sutcliffe (ir0nh34d)
Summary: Add CreateSymbolicLink declaration
Initial Comment:
Publicly available documentation was used to create this patch
http://msdn.microsoft.com/en-us/library/aa363866%28VS.85%29.aspx
----------------------------------------------------------------------
> Comment By: Keith Marshall (keithmarshall)
Date: 2010-08-18 10:50
Message:
Looks good to me. If you'd care to add a ChangeLog entry, (in GCS format),
it will likely be committed quicker; if you wait for one of us to write it,
it may take (considerably) longer.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=302435&aid=3047566&group_id=2435
------------------------------
Message: 2
Date: Wed, 18 Aug 2010 11:07:48 +0000
From: SF/projects/mingw notification list
<mingw-notify@lists.sourceforge.net>
Subject: [MinGW-notify] [ mingw-Patches-3047566 ] Add
CreateSymbolicLink declaration
To: noreply@sourceforge.net
Message-ID: <E1OlgUm-0006Rd-91@sfs-web-6.v29.ch3.sourceforge.com>
Content-Type: text/plain; charset="UTF-8"
Patches item #3047566, was opened at 2010-08-18 10:40
Message generated for change (Comment added) made by ladis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=302435&aid=3047566&group_id=2435
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: w32api
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Ladislav Michl (ladis)
Assigned to: Chris Sutcliffe (ir0nh34d)
Summary: Add CreateSymbolicLink declaration
Initial Comment:
Publicly available documentation was used to create this patch
http://msdn.microsoft.com/en-us/library/aa363866%28VS.85%29.aspx
----------------------------------------------------------------------
Comment By: Ladislav Michl (ladis)
Date: 2010-08-18 13:07
Message:
Uploaded new version of patch with Changelog entry.
----------------------------------------------------------------------
Comment By: Keith Marshall (keithmarshall)
Date: 2010-08-18 12:50
Message:
Looks good to me. If you'd care to add a ChangeLog entry, (in GCS format),
it will likely be committed quicker; if you wait for one of us to write it,
it may take (considerably) longer.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=302435&aid=3047566&group_id=2435
------------------------------
Message: 3
Date: Wed, 18 Aug 2010 11:37:30 +0000
From: SF/projects/mingw notification list
<mingw-notify@lists.sourceforge.net>
Subject: [MinGW-notify] [ mingw-Patches-3047571 ] Fix order of
msys_symlink arguments
To: noreply@sourceforge.net
Message-ID: <E1OlgxW-0007Mn-D3@sfs-web-4.v29.ch3.sourceforge.com>
Content-Type: text/plain; charset="UTF-8"
Patches item #3047571, was opened at 2010-08-18 08:46
Message generated for change (Comment added) made by keithmarshall
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=302435&aid=3047571&group_id=2435
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: msys
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Ladislav Michl (ladis)
> Assigned to: Cesar Strauss (cstrauss)
Summary: Fix order of msys_symlink arguments
Initial Comment:
According to POSIX standard symlink name is second argument
http://www.opengroup.org/onlinepubs/009695399/functions/symlink.html
No functional changes otherwise, except memory is no longer leaked
when creating symlink to directory.
----------------------------------------------------------------------
> Comment By: Keith Marshall (keithmarshall)
Date: 2010-08-18 11:37
Message:
Thanks for the patch. I'll leave it for Cesar, to conduct a detailed
review, but just one comment, on cursory inspection:
The semantics of copying and linking are quite different; while it is
quite correct that the POSIX spec for the symlink() function places the
'topath' argument first, followed by the 'frompath', (i.e. we follow the
reference from the created link to the target data), is it really
imperative that we maintain this relationship within what is purely an
internal implementation detail? IOW, while it may make sense to reverse
the argument order to msys_symlink(), it perhaps isn't essential. The
symlink() function, as implemented in path.cc already appears to provide a
POSIXly correct API; that the argument order appears to be reversed when
calling the msys_symlink() helper may be a potential cause of confusion,
but it is an internal detail, which isn't really problematic provided it is
applied consistently at every point of use.
OTOH, the reversal of the order of the first two arguments to
RecursiveCopy, while also an internal detail, just seems semantically
wrong. At a shell prompt, we express the command to create a symbolic link
as:
ln -s topath frompath
with the argument order semantically matching the order of arguments to be
passed to the symlink() function. However, to perform a recursive copy, we
express the command as:
cp -r frompath topath
Note the semantic difference. In both cases, the final argument
represents what is to be created, and the preceding argument specifies
whence the data is to be sourced, but in the case of the copy operation, we
copy the data from the source to the destination, whereas in the case of
linking, we refer from the *destination* back to the source.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=302435&aid=3047571&group_id=2435
------------------------------
Message: 4
Date: Wed, 18 Aug 2010 11:51:53 +0000
From: SF/projects/mingw notification list
<mingw-notify@lists.sourceforge.net>
Subject: [MinGW-notify] [ mingw-Patches-3047571 ] Fix order of
msys_symlink arguments
To: noreply@sourceforge.net
Message-ID: <E1OlhBR-0008LR-Lt@sfs-web-3.v29.ch3.sourceforge.com>
Content-Type: text/plain; charset="UTF-8"
Patches item #3047571, was opened at 2010-08-18 10:46
Message generated for change (Comment added) made by ladis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=302435&aid=3047571&group_id=2435
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: msys
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Ladislav Michl (ladis)
Assigned to: Cesar Strauss (cstrauss)
Summary: Fix order of msys_symlink arguments
Initial Comment:
According to POSIX standard symlink name is second argument
http://www.opengroup.org/onlinepubs/009695399/functions/symlink.html
No functional changes otherwise, except memory is no longer leaked
when creating symlink to directory.
----------------------------------------------------------------------
Comment By: Ladislav Michl (ladis)
Date: 2010-08-18 13:51
Message:
Well, the patch was ment as a preparation for native symlink merge.
In the long term plan, I'd like to rewrite path.cc without all cygwin
leftovers and let symlink function exist only in symlink.cc. Therefore
I swapped argument of msys_symlink function which is now
'internal implementation', but as symlink function only call this one,
I'd like to remove it and rename msys_symlink to symlink
(assuming cygwin fork happened only once, and there are no plans
to merge with 'upstream')
As far as RecursiveCopy goes, I did it just for convenience, to
make it consistent with msys_symlink and I do agree, that
these arguments would be better named src and dst.
Shall I update patch this way?
----------------------------------------------------------------------
Comment By: Keith Marshall (keithmarshall)
Date: 2010-08-18 13:37
Message:
Thanks for the patch. I'll leave it for Cesar, to conduct a detailed
review, but just one comment, on cursory inspection:
The semantics of copying and linking are quite different; while it is
quite correct that the POSIX spec for the symlink() function places the
'topath' argument first, followed by the 'frompath', (i.e. we follow the
reference from the created link to the target data), is it really
imperative that we maintain this relationship within what is purely an
internal implementation detail? IOW, while it may make sense to reverse
the argument order to msys_symlink(), it perhaps isn't essential. The
symlink() function, as implemented in path.cc already appears to provide a
POSIXly correct API; that the argument order appears to be reversed when
calling the msys_symlink() helper may be a potential cause of confusion,
but it is an internal detail, which isn't really problematic provided it is
applied consistently at every point of use.
OTOH, the reversal of the order of the first two arguments to
RecursiveCopy, while also an internal detail, just seems semantically
wrong. At a shell prompt, we express the command to create a symbolic link
as:
ln -s topath frompath
with the argument order semantically matching the order of arguments to be
passed to the symlink() function. However, to perform a recursive copy, we
express the command as:
cp -r frompath topath
Note the semantic difference. In both cases, the final argument
represents what is to be created, and the preceding argument specifies
whence the data is to be sourced, but in the case of the copy operation, we
copy the data from the source to the destination, whereas in the case of
linking, we refer from the *destination* back to the source.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=302435&aid=3047571&group_id=2435
------------------------------
Message: 5
Date: Wed, 18 Aug 2010 13:02:55 +0000
From: SF/projects/mingw notification list
<mingw-notify@lists.sourceforge.net>
Subject: [MinGW-notify] [ mingw-Patches-3047571 ] Fix order of
msys_symlink arguments
To: noreply@sourceforge.net
Message-ID: <E1OliIB-00067G-BM@sfs-web-7.v29.ch3.sourceforge.com>
Content-Type: text/plain; charset="UTF-8"
Patches item #3047571, was opened at 2010-08-18 04:46
Message generated for change (Comment added) made by earnie
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=302435&aid=3047571&group_id=2435
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: msys
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Ladislav Michl (ladis)
Assigned to: Cesar Strauss (cstrauss)
Summary: Fix order of msys_symlink arguments
Initial Comment:
According to POSIX standard symlink name is second argument
http://www.opengroup.org/onlinepubs/009695399/functions/symlink.html
No functional changes otherwise, except memory is no longer leaked
when creating symlink to directory.
----------------------------------------------------------------------
> Comment By: Earnie Boyd (earnie)
Date: 2010-08-18 09:02
Message:
As it stands I don't know that there is any reason to think of any plans
for merging upstream. More likely merging upstream to the fork may happen,
at least that is the reason for the msys_symlink that and easily
recognizing which code went with the fork. I'll let Cesar decide if the
functionality should be merged back to symlink.
----------------------------------------------------------------------
Comment By: Ladislav Michl (ladis)
Date: 2010-08-18 07:51
Message:
Well, the patch was ment as a preparation for native symlink merge.
In the long term plan, I'd like to rewrite path.cc without all cygwin
leftovers and let symlink function exist only in symlink.cc. Therefore
I swapped argument of msys_symlink function which is now
'internal implementation', but as symlink function only call this one,
I'd like to remove it and rename msys_symlink to symlink
(assuming cygwin fork happened only once, and there are no plans
to merge with 'upstream')
As far as RecursiveCopy goes, I did it just for convenience, to
make it consistent with msys_symlink and I do agree, that
these arguments would be better named src and dst.
Shall I update patch this way?
----------------------------------------------------------------------
Comment By: Keith Marshall (keithmarshall)
Date: 2010-08-18 07:37
Message:
Thanks for the patch. I'll leave it for Cesar, to conduct a detailed
review, but just one comment, on cursory inspection:
The semantics of copying and linking are quite different; while it is
quite correct that the POSIX spec for the symlink() function places the
'topath' argument first, followed by the 'frompath', (i.e. we follow the
reference from the created link to the target data), is it really
imperative that we maintain this relationship within what is purely an
internal implementation detail? IOW, while it may make sense to reverse
the argument order to msys_symlink(), it perhaps isn't essential. The
symlink() function, as implemented in path.cc already appears to provide a
POSIXly correct API; that the argument order appears to be reversed when
calling the msys_symlink() helper may be a potential cause of confusion,
but it is an internal detail, which isn't really problematic provided it is
applied consistently at every point of use.
OTOH, the reversal of the order of the first two arguments to
RecursiveCopy, while also an internal detail, just seems semantically
wrong. At a shell prompt, we express the command to create a symbolic link
as:
ln -s topath frompath
with the argument order semantically matching the order of arguments to be
passed to the symlink() function. However, to perform a recursive copy, we
express the command as:
cp -r frompath topath
Note the semantic difference. In both cases, the final argument
represents what is to be created, and the preceding argument specifies
whence the data is to be sourced, but in the case of the copy operation, we
copy the data from the source to the destination, whereas in the case of
linking, we refer from the *destination* back to the source.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=302435&aid=3047571&group_id=2435
------------------------------
Message: 6
Date: Wed, 18 Aug 2010 13:30:04 +0000
From: SF/projects/mingw notification list
<mingw-notify@lists.sourceforge.net>
Subject: [MinGW-notify] [ mingw-Patches-3046195 ] Native symlinks
To: noreply@sourceforge.net
Message-ID: <E1OliiS-0006v4-Vg@sfs-web-5.v29.ch3.sourceforge.com>
Content-Type: text/plain; charset="UTF-8"
Patches item #3046195, was opened at 2010-08-16 07:29
Message generated for change (Comment added) made by earnie
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=302435&aid=3046195&group_id=2435
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: msys
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Ladislav Michl (ladis)
Assigned to: Cesar Strauss (cstrauss)
Summary: Native symlinks
Initial Comment:
This premiliary patch contains support for native symlinks. See this thread: \
http://thread.gmane.org/gmane.comp.gnu.mingw.user/32432/
As I do not know which Windows versions are officially supported by MSYS, \
create_symlink function is not implemented as it is available since Vista. Original \
patch had CreateSymbolicLink dynamically loaded based on Windows version, but since \
CreateHardLink is used directly (and IsWow54Process elsewhere as well), lets leave \
actual implementation once this question is resolved.
msys_symlink was called from path.cc with arguments swapped, so fix both caller and \
callee. At least this part of patch would deserve merging.
Also it turned out, that symlinks are actually easy to implement, but learning the \
rest of MSYS about their existence is much harder. There is some code trying to \
resolve .lnk files as well as code which stores symlink info into NTFS extended \
attributes and also code implementing links with BackupWrite. Everything probably \
inherited from Cygwin. How should it be done in MSYS?
Interestingly enough BackupWrite approach uses fallback semantics. If 'symlink' \
cannot be created, file copy is performed. On Linux link syscall returns -EPERM on \
FAT filesystem (and I would expect -ENOTSUPP). I'd rather avoid silent fallback, or \
make that optional.
More comments later, there is already enough questions asked.
Thank you,
ladis
----------------------------------------------------------------------
> Comment By: Earnie Boyd (earnie)
Date: 2010-08-18 09:30
Message:
> 3) If the OS/FS supports reparse points for the type of entity to be
> linked, attempt to create one; return immediately on success, otherwise
> proceed to (4).
Be careful here. I have been able to create reparse points for files and
MSYS programs use the file but native programs cannot. We do not want to
make use of an undocumented feature.
----------------------------------------------------------------------
Comment By: Cesar Strauss (cstrauss)
Date: 2010-08-18 06:39
Message:
> Well, my understanding is quite opposite and as implemented in
> patch - content of the symbolic link (topath) is the first argument.
> As symlink name points to symlink content.
You are right, sorry by the confusion. I was still thinking in terms of
symlink-as-copy, where you copy *from* the original path *to* its new
destination.
> > We need MSYS to DTRT, when a developer blindly uses ln -s,
> > without checking that it does, in fact, work.
OK.
> I would very much appreciate if this could be done by
> someone more familiar with MSYS, but in the worst case
> I can do it myself (it will take me quite some time).
I can't say I am an expert on this part of the code, but I'll try to help.
Unfortunately, I currently have access only to Windows XP and 95
installations, so I really have no way to test the symlink part.
As for your previous question on the mailing list:
> where to hook code supposed to run only once at dll startup?
A place would be in dcrt0.cc (dll_crt0_1).
Regards,
Cesar
----------------------------------------------------------------------
Comment By: Keith Marshall (keithmarshall)
Date: 2010-08-18 05:11
Message:
Ladis,
> > It's hardly the epitome of clarity!
>
> As I have problem understanding the meaning
> of above sentence (irony?)
No irony intended on my part, but perhaps ironic that you had difficulty
understanding. I'm guessing that your problem may be with "epitome":
http://oxforddictionaries.com/search?q=epitome
Hence, even as a native English speaker I found the wording of the POSIX
spec to be confusing, so little wonder that you and Cesar, (for both of
whom English is, presumably, a second language), may have interpreted it
differently. Just to confirm: having read it several times, and having
sought additional clarification from the manpage on my Ubuntu box, I concur
with your interpretation, rather than Cesar's.
> > We need MSYS to DTRT, when a developer blindly uses
> > ln -s, without checking that it does, in fact, work.
>
> Agree. My only concern is that fallback should be configurable.
> 1) Symlink using (recursive) copy
> 2) Use symlinks, fail with -EPERM if impossible (*)
> 3) Use symlinks, fallback to 1) if impossible.
To me, making it (somehow) configurable seems like overkill. Rather,
perform just one consistent sequence of operations, in *all* cases:
1) Attempt to create a (true) symbolic link; if the OS/FS cannot support
that, the attempt will report failure, in which case we proceed to (2); if
it succeeds, we are done, so immediately return, reporting success.
2) If the entity to be linked to is a *file*, attempt to create a *hard*
link; if that succeeds, then we are done and can return immediately;
otherwise we proceed to (3).
3) If the OS/FS supports reparse points for the type of entity to be
linked, attempt to create one; return immediately on success, otherwise
proceed to (4).
4) If the entity to be linked is a file, substitute a simple file copy for
the link; otherwise recursively replicate the directory structure, and
attempt to hard link individual files into the appropriate duplicate
location; substitute file copies, if hard linking fails.
> Yet no one wants to write path.cc functional analysis?
Personally, I am not sufficiently familiar with it to do that. Cesar is
probably best equipped to do so, but he may not wish to devote the time it
would take.
----------------------------------------------------------------------
Comment By: Ladislav Michl (ladis)
Date: 2010-08-18 04:50
Message:
Created 3047566 and removed CreateSymbolicLink patch from here.
Fix for msys_symlink argument order added as 3047571.
I'll update this patch once merged.
----------------------------------------------------------------------
Comment By: Earnie Boyd (earnie)
Date: 2010-08-17 15:13
Message:
> As I do not like mixing bugfix, cosmetic changes and actual new
> features is anyone interested in separate patch? Should I open
> new ticket? Should I do the same for w32api?
Yes, these should be separated.
----------------------------------------------------------------------
Comment By: Ladislav Michl (ladis)
Date: 2010-08-17 12:44
Message:
> It's hardly the epitome of clarity!
As I have problem understanding the meaning of above sentence (irony?)
I'd rather clarify: POSIX specification is accurate and I understand it
the
opposite way Cesar wrote.
As I do not like mixing bugfix, cosmetic changes and actual new
features is anyone interested in separate patch? Should I open
new ticket? Should I do the same for w32api?
> However, there is still an extensive corpus of projects which *don't*
> use autoconf, and thus may *not* DTRT when they use ln -s. Indeed,
> there are still many developers who continue to believe that they
> can write better configure scripts by hand, than autoconf can
> generate; (they can't, but convincing them of this fundamental
> reality is very difficult).
Here I assume DTRT means "Do The Right Thing". And, well, reality
is that most people can't write proper configure script either way.
I'm mostly cross-compiling and there are vast minority of packages
which 'just work'. However, this does not mean MSYS should make
things any worse.
> We need MSYS to DTRT, when a developer blindly uses ln -s,
> without checking that it does, in fact, work.
Agree. My only concern is that fallback should be configurable.
1) Symlink using (recursive) copy
2) Use symlinks, fail with -EPERM if impossible (*)
3) Use symlinks, fallback to 1) if impossible.
(*) It would be more accurate to return -ENOTSUPP here, but
Linux manpage states: "EPERM The file system containing
newpath does not support the creation of symbolic links."
and POSIX does not specify this situation at all.
environ.cc already contains definition of winsymlinks variable,
but its type is bool. Is it acceptable to change that?
Yet noone wants to write path.cc functional analysis? I'll wait
a bit longer... ;-)
----------------------------------------------------------------------
Comment By: Keith Marshall (keithmarshall)
Date: 2010-08-17 10:32
Message:
> > Please swap the order of the arguments of the symlink function
> > itself as well. According to the POSIX standard, the contents of
> > the symbolic link (frompath) is the first argument. To see it,
> > type "symlink" on the search box in the following page:
> > http://www.opengroup.org/onlinepubs/009695399/
>
> http://www.opengroup.org/onlinepubs/009695399/functions/symlink.html
>
> int symlink(const char *path1, const char *path2);
>
> The symlink() function shall create a symbolic link called path2
> that contains the string pointed to by path1 ( path2 is the name
> of the symbolic link created, path1 is the string contained in the
> symbolic link).
>
> Well, my understanding is quite opposite and as implemented in
> patch - content of the symbolic link (topath) is the first argument.
> As symlink name points to symlink content.
It's hardly the epitome of clarity! The order of the arguments to the
POSIX symlink() function is the same as used in the ln -s command; i.e. the
first argument is the existing path name of the entity to which the link
will refer, and the second specifies the link entity to be created.
Logically, I would interpret a symlink as pointing from the created link
entity to the original entity, and thus I would expect the terminology to
refer to the first argument as 'topath' and the second as 'frompath'; i.e.
my understanding matches Ladis' interpretation.
----------------------------------------------------------------------
Comment By: Keith Marshall (keithmarshall)
Date: 2010-08-17 10:06
Message:
> > Autoconf currently has an AC_PROG_LN_S macro
> > which will set the $(LN_S) variable to either "ln -s",
> > "ln" or "cp -p", depending on the host capabilities.
> > Given this, is there any longer a need for the
> > symlink-as-copy fallback to be on by default
> > on MSYS?
>
> Testing is the only way to know but I would guess
> it would still be needed.
IMO, it is still very much needed. Certainly, there are many projects
using autoconf, and provided they've used AC_PROG_LN_S, and substituted
LN_S appropriately in their makefiles, then they will most likely DTRT.
However, there is still an extensive corpus of projects which *don't* use
autoconf, and thus may *not* DTRT when they use ln -s. Indeed, there are
still many developers who continue to believe that they can write better
configure scripts by hand, than autoconf can generate; (they can't, but
convincing them of this fundamental reality is very difficult). We need
MSYS to DTRT, when a developer blindly uses ln -s, without checking that it
does, in fact, work.
----------------------------------------------------------------------
Comment By: Earnie Boyd (earnie)
Date: 2010-08-17 08:33
Message:
> Given this, is there any longer a need for the symlink-as-copy fallback to
be on by default on MSYS?
Testing is the only way to know but I would guess it would still be
needed.
----------------------------------------------------------------------
Comment By: Ladislav Michl (ladis)
Date: 2010-08-17 07:29
Message:
> Please see the source in autoload.cc. If you add a CreateSymbolicLink
> declaration in there, you can call it in the code directly. You are
> actually calling a stub code that will load the appropriate library by
> demand, and either forward your call to the real function, or return
FALSE
> if it doesn't exists in your version of Windows.
Very interesting, usefull and explains my questions. I added
CreateSymbolicLink to the w32api (patch attached) and modified
autoload.cc accordingly.
> Please swap the order of the arguments of the symlink function itself as
> well. According to the POSIX standard, the contents of the symbolic link
> (frompath) is the first argument. To see it, type "symlink" on the
search
> box in the following page:
> http://www.opengroup.org/onlinepubs/009695399/
http://www.opengroup.org/onlinepubs/009695399/functions/symlink.html
int symlink(const char *path1, const char *path2);
The symlink() function shall create a symbolic link called path2 that
contains the string pointed to by path1 ( path2 is the name of the
symbolic link created, path1 is the string contained in the symbolic
link).
Well, my understanding is quite opposite and as implemented in
patch - content of the symbolic link (topath) is the first argument.
As symlink name points to symlink content.
$ touch file
$ ln -s file link
$ ls -l
-rw-r--r-- 1 ladis ladis 0 2010-08-17 14:52 file
lrwxrwxrwx 1 ladis ladis 4 2010-08-17 14:52 link -> file
in patched MSYS with debug enabled, you get:
$ ln -s file link
msys_symlink (file, link)
create_copy_file (C:\MSYS\test\file, C:\MSYS\test\link)
as you can see, symlink points from 'link' (second argument) to 'file'
(first argument).
> It would be nice to display symlink info in "ls -l".
> Maybe a start would be updating the symlink_info::check method.
I read symlink_info::check method yesterday as well as the rest of that
file
and now after more than 12 hours I'm able to comment it without showing
too much emotions. Ummm... So, the only sane way how to update path.cc
is to downwrite its desired function and then implement it as it keeps all
cygwin logic which has no use for us and make code very hard to
understand and modify (someone already tried to do so). I would
very much appreciate if this could be done by someone more familiar with
MSYS, but in the worst case I can do it myself (it will take me quite some
time).
> I guess you should ensure the following system calls are aware of
> symlinks: stat, lstat and readlink (you can read about them in the POSIX
> standard link I gave above).
Actually the most important is unlink and remove as they are not junctions
aware.
> Autoconf currently has an AC_PROG_LN_S macro which will set the
> $(LN_S) variable to either "ln -s", "ln" or "cp -p", depending on the
> host capabilities. Given this, is there any longer a need for the
> symlink-as-copy fallback to be on by default on MSYS?
I modified the patch to provide some fallback logic, which is currently
disabled and copy method used. Easy to fix once we came to a
conclusion.
----------------------------------------------------------------------
Comment By: Cesar Strauss (cstrauss)
Date: 2010-08-16 23:12
Message:
> As I do not know which Windows versions are officially supported by
> MSYS, create_symlink function is not implemented as it is available
> since Vista. Original patch had CreateSymbolicLink dynamically loaded
> based on Windows version, but since CreateHardLink is used directly
> (and IsWow54Process elsewhere as well), lets leave actual
> implementation once this question is resolved.
Please see the source in autoload.cc. If you add a CreateSymbolicLink
declaration in there, you can call it in the code directly. You are
actually calling a stub code that will load the appropriate library by
demand, and either forward your call to the real function, or return FALSE
if it doesn't exists in your version of Windows.
> msys_symlink was called from path.cc with arguments swapped, so fix
both
> caller and callee. At least this part of patch would deserve merging.
Please swap the order of the arguments of the symlink function itself as
well. According to the POSIX standard, the contents of the symbolic link
(frompath) is the first argument. To see it, type "symlink" on the search
box in the following page:
http://www.opengroup.org/onlinepubs/009695399/
> Also it turned out, that symlinks are actually easy to implement, but
> learning the rest of MSYS about their existence is much harder. There
> is some code trying to resolve .lnk files as well as code which stores
> symlink info into NTFS extended attributes and also code implementing
> links with BackupWrite. Everything probably inherited from Cygwin. How
> should it be done in MSYS?
It would be nice to display symlink info in "ls -l".
Maybe a start would be updating the symlink_info::check method.
I guess you should ensure the following system calls are aware of
symlinks: stat, lstat and readlink (you can read about them in the POSIX
standard link I gave above).
Earnie writes:
> If the OS and/or file system does not support CreateSymbolicLink then a
> copy of the file is correct for what we need. Too many configure
scripts
> use ln -s to not have the fallback of copy by default.
Autoconf currently has an AC_PROG_LN_S macro which will set the $(LN_S)
variable to either "ln -s", "ln" or "cp -p", depending on the host
capabilities. Given this, is there any longer a need for the
symlink-as-copy fallback to be on by default on MSYS?
Regards,
Cesar
----------------------------------------------------------------------
Comment By: Earnie Boyd (earnie)
Date: 2010-08-16 08:09
Message:
> Also it turned out, that symlinks are actually easy to implement, but
> learning the rest of MSYS about their existence is much harder. There
> is some code trying to resolve .lnk files as well as code which
> stores symlink info into NTFS extended attributes and also code
> implementing links with BackupWrite. Everything probably inherited
> from Cygwin. How should it be done in MSYS?
Yes, the .lnk code was inherited from Cygwin. I disabled it because
Windows native programs do not understand .lnk files. For directories I
would suggest using Reparse (Junction) Points. For files I would suggest
that if the OS and file system supports it we use the CreateSymbolicLink.
If the OS and/or file system does not support CreateSymbolicLink then a
copy of the file is correct for what we need. Too many configure scripts
use ln -s to not have the fallback of copy by default.
Cesar Strauss is the current maintainer. He may have more to say.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=302435&aid=3046195&group_id=2435
------------------------------
------------------------------------------------------------------------------
This SF.net email is sponsored by
Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev
------------------------------
_______________________________________________
MinGW-notify mailing list
MinGW-notify@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-notify
End of MinGW-notify Digest, Vol 51, Issue 7
*******************************************
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic