From: Erwin W. <wat...@xs...> - 2010-03-15 08:29:19
|
Op 14-03-10 12:39, Mansour Al Akeel schreef: > Hello all: > > I extracted all the files from the MinGW over a directory where I have > installed GnuWin32 tools installed. Then I installed MSYS and mounted > MinGW as usual. The reason I used GnuWin32 is because of the tools that > it contains. I am not sure if this will work. Any advice ? > I would keep GnuWin32 and MSYS installation separate. That's what I do. It's better to use MSYS tools in MSYS, because they better cooperate with MSYS bash. They work for instance natively with msys directory paths. MSYS tool ports are also more up-to-date. GnuWin32 tools are targeted for cmd.exe, but can work in MSYS as well. In MSYS you can add the GnuWin32 bin directory to PATH to add GnuWin32 tools you miss in MSYS. |
From: Keith M. <kei...@us...> - 2010-03-14 15:18:16
|
On Sunday 14 March 2010 08:05:03 Erwin Waterlander wrote: > > Have you tried to build/port the programs? It certainly has > > merit and could become part of mingw-utils if it just works. > > > > I found the sources in the DJGPP developers kit. > ftp://ftp.delorie.com/pub/djgpp/current/v2/djlsr203.zip > Porting is not so easy. Parts are written in assembly. Why not just write something from scratch? You basically want a simple stub loader, (even simpler than the one I've written for mingw-get[*]), which identifies the real program to run, (perhaps from a patched string within its own image, or alternatively by reading from a related "symlink" file), and invokes that via spawnv (or execv, or even CreateProcess if you are a masochist), passing the arguments from your original command line[**]. It could be something almost as trivial as (untested): #include <process.h> /* or maybe prefer execwrap.h [**] */ int main( int argc, char **argv ) { static char symlink[_MAX_PATH] = "<target-executable-name>"; return spawnv( _P_WAIT, symlink, argv ); } [*]http://mingw.cvs.sourceforge.net/viewvc/mingw/mingw-get/src/clistub.c?revision=1.3&view=markup [**] Watch out for argument quoting gotchas -- you might like to consider using our GPLed libexecwrap.a, to avoid them. Also note that execv() is semantically broken on MS-Windows; if you use it in a CLI stub, your child process will run detached, in background, and your stub will return you immediately to the CLI prompt, *without* waiting for the child to complete. (Of course, the same applies to a GUI stub, but the effect may be less noticeable). Use spawnv( _P_WAIT, ... ) to avoid this effect. > It's a *long* time ago [since] I [wrote assembly code], and that > wasn't on intel CPUs. I used to write a lot of assembly code for MS-DOS, but that was in Intel syntax; the AT&T syntax favoured by GAS, coupled with GAS' own cryptic pseudo-opcodes, conveys about as much sense to me as would ancient Egyptian hieroglyphs. |
From: LRN <lr...@gm...> - 2010-03-08 23:02:57
|
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). |
From: Vincent R. <fo...@sm...> - 2010-03-09 00:14:39
|
> 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. >> >> Yes and cygwin is already able to identify them. > 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. I found something very interesting while I was observing what happens when I call mklink to create a symlink on Windows 7 and it's called CreateSymbolicLinkW (http://msdn.microsoft.com/en-us/library/aa363866%28VS.85%29.aspx) It works with file and folder but now I have the same issue ie how to make distinction between a symlink and a hardlink. If someone wants to read very carefully msdn... |
From: Earnie <ea...@us...> - 2010-03-09 00:24:34
|
Vincent Richomme wrote: > I found something very interesting while I was observing what happens > when I call mklink to create a symlink on Windows 7 and it's called > CreateSymbolicLinkW > (http://msdn.microsoft.com/en-us/library/aa363866%28VS.85%29.aspx) > It works with file and folder but now I have the same issue ie how to make > distinction > between a symlink and a hardlink. If someone wants to read very carefully > msdn... > Yes, even on XP. The junction point actually works for a file but idiot Windows explorer goes out of its way to make it not recognized. However, windows programs you code yourself do. This could change without notice since it is definitely not the documented feature of junction points. Earnie |
From: Vincent R. <fo...@sm...> - 2010-03-09 00:39:05
|
On Mon, 08 Mar 2010 19:24:19 -0500, Earnie <ea...@us...> wrote: > Vincent Richomme wrote: >> I found something very interesting while I was observing what happens >> when I call mklink to create a symlink on Windows 7 and it's called >> CreateSymbolicLinkW >> (http://msdn.microsoft.com/en-us/library/aa363866%28VS.85%29.aspx) >> It works with file and folder but now I have the same issue ie how to >> make >> distinction >> between a symlink and a hardlink. If someone wants to read very carefully >> msdn... >> > > Yes, even on XP. The junction point actually works for a file but idiot > Windows explorer goes out of its way to make it not recognized. > However, windows programs you code yourself do. This could change > without notice since it is definitely not the documented feature of > junction points. > Don't know about XP since doc says Windows Vista minimum. And all those symlink, junctions ... are only interesting started from Vista because as you wrote, on XP windows explorer does stupid things. |
From: Keith M. <kei...@us...> - 2010-03-09 17:42:20
|
On Monday 08 March 2010 23:02:41 LRN wrote: > > 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. That was what I understood, from a cursory examination of your code. > >> 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, Indeed. However, it shouldn't matter. If, in MSYS-1.0.11 with the coreutils-5.97 build of ln, I do: $ touch foo $ ln -s foo bar it appears that the request to create a symbolic link is serviced by the equivalent of: $ cp -p foo bar It does not appear to fall back to using a hard link, although that would be an equally acceptable, (some may say more acceptable), fall back option, where the file system can support hard links. In any case, it is immaterial whether the symbolic link is simulated by a copy or by a hard link; a subsequent: $ rm foo should unlink foo, leaving bar in place, and conversely: $ rm bar should unlink bar, leaving foo in place. If I extend this, to work with directory-to-directory symbolic link simulation: $ mkdir -p fie foe/fum $ touch foe/bar foe/fum/foo $ ( cd fie ; ln -s ../foe foe ) I find that ./fie/foe is created as a recursively copied directory image of ./foe, as if I'd executed: $ ( cd fie ; cp -rp ../foe foe ) as the final command in the preceding triplet. Now, IMO the current fallback action for a file-to-file symbolic link is a reasonable compromise, but a junction point would be a more reasonable option for the directory-to-directory case, where the file system can support it. I'm not suggesting that your libntlink should become part of MSYS; (on the contrary, I would actually oppose that). What I am suggesting is that you exploit your experience, gained while developing libntlink, to formulate patches against MSYS' ln, ls and rm sources, and if necessary, msys-1.0.dll sources, to implement this enhancement. > 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. You are over-thinking it. A hard link can only ever exist in the file-to-file linking case, and if rm is asked to unlink one member of the linked collection, it is *always* correct for it to do just that, irrespective of whether the link is hard or symbolic. OTOH, in the directory-to-directory case, with a junction used to simulate the symbolic link, then: $ rm dirlink should simply destroy the junction point, without touching its target directory in any way. In the current fallback situation, where the directory symbolic link is simulated by a recursive directory copy, that correct action cannot occur; the user must explicitly: $ rm -r dirlink (In this respect the recursive copy fallback *doesn't* adequately simulate the effect of a true symbolic link implementation, and may thus be considered to be broken; it would be quite wrong for any script, expecting symbolic link semantics, to issue an `rm -r ...' command on the symbolic link, when the intent is to remove only the link itself). -- Regards, Keith. |
From: Earnie <ea...@us...> - 2010-03-14 16:32:25
|
Keith Marshall wrote: > > I used to write a lot of assembly code for MS-DOS, but that was in > Intel syntax; the AT&T syntax favoured by GAS, coupled with GAS' own > cryptic pseudo-opcodes, conveys about as much sense to me as would > ancient Egyptian hieroglyphs. > As of version 2.10 binutils supports the Intel Syntax. http://sourceware.org/binutils/docs/as/i386_002dSyntax.html#i386_002dSyntax Earnie |
From: Keith M. <kei...@us...> - 2010-03-14 17:52:36
|
On Sunday 14 March 2010 16:32:12 Earnie wrote: > > I used to write a lot of assembly code for MS-DOS, but that was > > in Intel syntax; the AT&T syntax favoured by GAS, coupled with > > GAS' own cryptic pseudo-opcodes, conveys about as much sense to > > me as would ancient Egyptian hieroglyphs. > > As of version 2.10 binutils supports the Intel Syntax. Supposedly, yes. However, we have seen bug reports recently, which suggest that using it *may* result in bad code; (I haven't verified this). I wonder if it gets the same level of attention and testing as does the AT&T syntax. That said, I think it's actually GAS' pseudo-ops that I find more intimidating than the AT&T syntax. Besides, today there is much less need to resort to assembly language; most things which could not have been achieved without it in MS-DOS can be accomplished in MS-Windows, using C. -- Regards, Keith. |