From: UnixOS2 Archive To: "UnixOS2 Archive" Date: Tue, 18 Feb 2003 04:53:40 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 48 ************************************************** Monday 17 February 2003 Number 48 ************************************************** Subjects for today 1 Re: ln : Dave Saville" 2 Re: ln : Marty" 3 Re: ln : Marty" 4 Re: ln : Marty" 5 Re: ln : Holger Veit 6 Re: ln : Bart van Leeuwen" 7 Re: ln : Holger Veit 8 Re: ln : Bart van Leeuwen" 9 Re: ln : Stefan Neis 10 Re: ln : John Poltorak 11 Re: ln : Holger Veit 12 Re: ln : Holger Veit 13 Re: ln : Holger Veit 14 Re: ln : Holger Veit 15 Re: PTHREADS : Adrian Gschwend" 16 Re: ln : Marty" 17 Re: Make v3.79.1 bug? : Andreas Buening **= Email 1 ==========================** Date: Tue, 18 Feb 2003 08:57:02 +0000 (GMT) From: "Dave Saville" Subject: Re: ln On Mon, 17 Feb 2003 20:18:15 -0500 (EST), Marty wrote: >Here's my proposal: >Create an LN executable that creates a blank file where the link is supposed to be. >The link target is stored in the extended attributes of this file. Next we modify >fopen, open, stat, etc., in our Unix compatibility libraries (be they EMX internals >or Posix/2) so that they check for these EAs before opening the file. > >Then just rebuild our shells and base utilities with these libraries and we're all >set (or if they're dynamically linked, we're ready to go without rebuilding). This >will give us soft link support in make and the various build scripts, which is >really all we need. It will also give any other apps we choose to rebuild the >ability to recognize these links. > >If we wanted to go all out, we could even make our routines recognize desktop >shadows, but that won't help our immediate cause (although it will make things >appear a lot more integrated with the OS/2 desktop). > >I'd be glad to take on this work if someone can point me to what I might need to >change in our support libraries (and where to get the source) to implement this, and >give me any pointers about the pitfalls involved. I'm sure someone has been down >this road before. I suggested some time back that it *might* be possible to create a "link object" along the lines of the URL object and when anything tries to open it it opens the "real" file. I have no idea if it is possible as I got zero feed back. Not even anyone saying it was a stupid idea :-) Assuming it is possible then the real nasty bit would be catching file name changes and moves as does OS/2 normally. -- Regards Dave Saville **= Email 2 ==========================** Date: Tue, 18 Feb 2003 09:21:51 -0500 (EST) From: "Marty" Subject: Re: ln On Tue, 18 Feb 2003 10:24:09 +0100, Holger Veit wrote: > The nasty thing is that the above might easily be integrated in either > EMX or Posix/2, but the drawback is that you would have to rely on > the UnixOS/2 environment to have links. You won't be able to reach > a symlinked file with a standard OS/2 editor anymore. If it helps us get some things built without script modifications, then it has accomplished its goal in my mind. **= Email 3 ==========================** Date: Tue, 18 Feb 2003 09:26:19 -0500 (EST) From: "Marty" Subject: Re: ln On Tue, 18 Feb 2003 14:19:10 +0100, Bart van Leeuwen wrote: > This was the counter argument I came up with myself as well.. but for what > purpose are we needing this ? > Building applications ? or general application use ? My argument is for the former. As far as using a separate filesystem, that seems really invasive to me (regardless of the performance). For general application use, look at it this way: how many applications can and do make use of shadows? Nothing but the WPS by my count. And I could write a WPS class to handle my links just like shadows if I wanted to go nuts. But from the user perspective, they won't be missing anything they already had. And from the developer perspective, this allows us to get more things built without modifications. **= Email 4 ==========================** Date: Tue, 18 Feb 2003 09:29:57 -0500 (EST) From: "Marty" Subject: Re: ln On Tue, 18 Feb 2003 14:27:31 +0100 (CET), Stefan Neis wrote: > It's not quite all we need. If "make install" does install a link for > "gunzip", I'd also expect it to work, when invoked e.g. from CMD.exe. Well, that won't happen. Just like shadows don't work from CMD. Really no difference there. It will work from a recompiled sh, however, which I think is really key to our work here. > AFAIK, we have somebody (Holger) working on a real (kernel > based) solution, so personally, I see no point in wasting a considerable > amount of effort on such a temporary hack. Sounds like that could take anywhere from a lot to an infinite amount of time. The "hack" code is easy, and I'd like to get something in place soon. **= Email 5 ==========================** Date: Tue, 18 Feb 2003 10:24:09 +0100 From: Holger Veit Subject: Re: ln On Tue, Feb 18, 2003 at 08:57:02AM +0000, Dave Saville wrote: > On Mon, 17 Feb 2003 20:18:15 -0500 (EST), Marty wrote: > > >Here's my proposal: > >Create an LN executable that creates a blank file where the link is supposed to be. > >The link target is stored in the extended attributes of this file. Next we modify > >fopen, open, stat, etc., in our Unix compatibility libraries (be they EMX internals > >or Posix/2) so that they check for these EAs before opening the file. > > > >Then just rebuild our shells and base utilities with these libraries and we're all > >set (or if they're dynamically linked, we're ready to go without rebuilding). This > >will give us soft link support in make and the various build scripts, which is > >really all we need. It will also give any other apps we choose to rebuild the > >ability to recognize these links. > > > >If we wanted to go all out, we could even make our routines recognize desktop > >shadows, but that won't help our immediate cause (although it will make things > >appear a lot more integrated with the OS/2 desktop). > > > >I'd be glad to take on this work if someone can point me to what I might need to > >change in our support libraries (and where to get the source) to implement this, and > >give me any pointers about the pitfalls involved. I'm sure someone has been down > >this road before. > > I suggested some time back that it *might* be possible to create a > "link object" along the lines of the URL object and when anything > tries to open it it opens the "real" file. I have no idea if it is > possible as I got zero feed back. Not even anyone saying it was a > stupid idea :-) You might have a look at ftp://ftp.dante.de/pub/tex/systems/os2/web2c-6.1/source/symlink.zip > Assuming it is possible then the real nasty bit would be catching > file name changes and moves as does OS/2 normally. The nasty thing is that the above might easily be integrated in either EMX or Posix/2, but the drawback is that you would have to rely on the UnixOS/2 environment to have links. You won't be able to reach a symlinked file with a standard OS/2 editor anymore. Holger -- Please update your tables to my new e-mail address: holger.veit$ais.fhg.de (replace the '$' with ' at ' -- spam-protection) **= Email 6 ==========================** Date: Tue, 18 Feb 2003 10:47:45 +0100 From: "Bart van Leeuwen" Subject: Re: ln Hi, I've been dealing with this issue for a while now, and I'm considering writting a NDFS plugin.. I've tried contacting the TVFS author on this subject, but it stays rather quiet from his side.. with NDFS you would get a dedicated Drive which supports symlinks, but all apps would be able to use this feature.. do I overlook something here ? do I miss a point ? or is this a possibility as well ? With Regards Bart van Leeuwen **= Email 7 ==========================** Date: Tue, 18 Feb 2003 14:02:41 +0100 From: Holger Veit Subject: Re: ln On Tue, Feb 18, 2003 at 10:47:45AM +0100, Bart van Leeuwen wrote: > > Hi, > > I've been dealing with this issue for a while now, and I'm considering > writting a NDFS plugin.. > I've tried contacting the TVFS author on this subject, but it stays rather > quiet from his side.. > > with NDFS you would get a dedicated Drive which supports symlinks, but all > apps would be able to use this feature.. > > do I overlook something here ? do I miss a point ? or is this a possibility > as well ? As TVFS shows, it is possible to do file redirection with an IFS. The price for this is that the file system reroutes all file accesses to a user process who then manages the whole file I/O for it. The file system itself cannot bend SFNs by itself, therefore it needs the user process working for it. This works well for some dozens of files or directories, but it is no real replacement for full blown hard/soft-linking, unfortunately. Holger -- Please update your tables to my new e-mail address: holger.veit$ais.fhg.de (replace the '$' with ' at ' -- spam-protection) **= Email 8 ==========================** Date: Tue, 18 Feb 2003 14:19:10 +0100 From: "Bart van Leeuwen" Subject: Re: ln On 18-02-2003 14:02:41 owner-os2-unix wrote: >On Tue, Feb 18, 2003 at 10:47:45AM +0100, Bart van Leeuwen wrote: >> >> Hi, >> >> I've been dealing with this issue for a while now, and I'm considering >> writting a NDFS plugin.. >> I've tried contacting the TVFS author on this subject, but it stays rather >> quiet from his side.. >> >> with NDFS you would get a dedicated Drive which supports symlinks, but all >> apps would be able to use this feature.. >> >> do I overlook something here ? do I miss a point ? or is this a possibility >> as well ? > >As TVFS shows, it is possible to do file redirection with an IFS. The price >for this is that the file system reroutes all file accesses to a user process >who then manages the whole file I/O for it. The file system itself cannot bend >SFNs by itself, therefore it needs the user process working for it. This works >well for some dozens of files or directories, but it is no real replacement >for full blown hard/soft-linking, unfortunately. This was the counter argument I came up with myself as well.. but for what purpose are we needing this ? Building applications ? or general application use ? for the later I must agree on your remarks about performance, but for the first this little overhead might be justified if it enables us to more easely port applications. Bart **= Email 9 ==========================** Date: Tue, 18 Feb 2003 14:27:31 +0100 (CET) From: Stefan Neis Subject: Re: ln Hi, > This will give us soft link support in make and the various build scripts, which is > really all we need. It will also give any other apps we choose to rebuild the > ability to recognize these links. It's not quite all we need. If "make install" does install a link for "gunzip", I'd also expect it to work, when invoked e.g. from CMD.exe. AFAIK, we have somebody (Holger) working on a real (kernel based) solution, so personally, I see no point in wasting a considerable amount of effort on such a temporary hack. Regards, Stefan **= Email 10 ==========================** Date: Tue, 18 Feb 2003 15:15:09 +0000 From: John Poltorak Subject: Re: ln On Tue, Feb 18, 2003 at 09:21:51AM -0500, Marty wrote: > On Tue, 18 Feb 2003 10:24:09 +0100, Holger Veit wrote: > > > The nasty thing is that the above might easily be integrated in either > > EMX or Posix/2, but the drawback is that you would have to rely on > > the UnixOS/2 environment to have links. You won't be able to reach > > a symlinked file with a standard OS/2 editor anymore. > > If it helps us get some things built without script modifications, then it has > accomplished its goal in my mind. Doesn't copying cp.exe to ln.exe help? -- John **= Email 11 ==========================** Date: Tue, 18 Feb 2003 18:08:01 +0100 From: Holger Veit Subject: Re: ln On Tue, Feb 18, 2003 at 03:15:09PM +0000, John Poltorak wrote: > On Tue, Feb 18, 2003 at 09:21:51AM -0500, Marty wrote: > > On Tue, 18 Feb 2003 10:24:09 +0100, Holger Veit wrote: > > > > > The nasty thing is that the above might easily be integrated in either > > > EMX or Posix/2, but the drawback is that you would have to rely on > > > the UnixOS/2 environment to have links. You won't be able to reach > > > a symlinked file with a standard OS/2 editor anymore. > > > > If it helps us get some things built without script modifications, then it has > > accomplished its goal in my mind. > > Doesn't copying cp.exe to ln.exe help? NO!!!!! cp understands some parameters that ln doesn't, and vice versa. Also the paramaeter sequences is reversed. But this is not the real problem, as this could be overcome by simply writing a "ln.exe" that internally just does copying. The point is much more severe: if you do cp instead of ln (-s), then you have later two independent files on the disk. Noone prevents you from modifying the first one and keeping the latter unchanged (this may happen unintenionally). Were they symlinked, or hardlinked, you would have modified both, and their content would still match. And this is not the only side effect: links are alias names, a means to rename files, a means to obfuscate file locations (they could actually be located on different disks without the user to worry about), a means to build cyclic dependencies into the tree (this is why lndir is root access only), and useful some other more or less creative applications. If links were the same as copies, they would be redundant. As they are not a redundant feature, they cannot be replaced by copying, without neglecting something significant. Holger -- Please update your tables to my new e-mail address: holger.veit$ais.fhg.de (replace the '$' with ' at ' -- spam-protection) **= Email 12 ==========================** Date: Tue, 18 Feb 2003 18:17:27 +0100 From: Holger Veit Subject: Re: ln On Tue, Feb 18, 2003 at 09:26:19AM -0500, Marty wrote: > On Tue, 18 Feb 2003 14:19:10 +0100, Bart van Leeuwen wrote: > > > This was the counter argument I came up with myself as well.. but for what > > purpose are we needing this ? > > Building applications ? or general application use ? > > My argument is for the former. As far as using a separate filesystem, that seems > really invasive to me (regardless of the performance). > > For general application use, look at it this way: how many applications can and do > make use of shadows? Nothing but the WPS by my count. And I could write a WPS > class to handle my links just like shadows if I wanted to go nuts. But from the > user perspective, they won't be missing anything they already had. And from the > developer perspective, this allows us to get more things built without > modifications. You cannot really compare shadows and links, even if both are restricted to some domain. You can explain people that WPS is WPS, and CMD is CMD, and therefore they behave differently. But you cannot explain people that emacs will touch a different C:\CONFIG.SYS than epm does (assuming you have managed to make a symlink to config.sys), and then, you cannot even further explain to them that the one handled with epm is the "right one" and the one with emacs is the "wrong one", although using emacs to edit the "wrong one" will actually modify the "right one". Confused already? What you'd expect is symmetry: if you have access to something in one domain, you'll expect it to behave independently from the tool that is valid for this domain. Symlinks are not the only stumbling block there; we have already the CRLF problem which, however, is traditionally handled by editors as it is so common. Holger -- Please update your tables to my new e-mail address: holger.veit$ais.fhg.de (replace the '$' with ' at ' -- spam-protection) **= Email 13 ==========================** Date: Tue, 18 Feb 2003 18:24:48 +0100 From: Holger Veit Subject: Re: ln On Tue, Feb 18, 2003 at 09:21:51AM -0500, Marty wrote: > On Tue, 18 Feb 2003 10:24:09 +0100, Holger Veit wrote: > > > The nasty thing is that the above might easily be integrated in either > > EMX or Posix/2, but the drawback is that you would have to rely on > > the UnixOS/2 environment to have links. You won't be able to reach > > a symlinked file with a standard OS/2 editor anymore. > > If it helps us get some things built without script modifications, then it has > accomplished its goal in my mind. The issue is not getting something built. The existence of all the Unix tools that are available for OS/2 already shows that this is possible somehow. The issue isn't to get something built easier either. The issue is to have a system named UnixOS/2 which *can be used*. You sacrifice the future usability for an easier life as a tool developer/porter. Not that I think that it should be as hard as possible to build or port something to OS/2, but l'art pour l'art ist not a useful motto for a work environment, IMHO. Holger -- Please update your tables to my new e-mail address: holger.veit$ais.fhg.de (replace the '$' with ' at ' -- spam-protection) **= Email 14 ==========================** Date: Tue, 18 Feb 2003 18:30:17 +0100 From: Holger Veit Subject: Re: ln On Tue, Feb 18, 2003 at 02:19:10PM +0100, Bart van Leeuwen wrote: [...] > >SFNs by itself, therefore it needs the user process working for it. This > works > >well for some dozens of files or directories, but it is no real > replacement > >for full blown hard/soft-linking, unfortunately. > > This was the counter argument I came up with myself as well.. but for what > purpose are we needing this ? > Building applications ? or general application use ? I always was under the impression that UnixOS/2 supposedly is an environment for general use, not just for the purpose of demonstration that it is possible to add yet another personality (DOS, OS/2, Win3.x, Odin, Unix) to OS/2. The latter is already proven. > for the later I must agree on your remarks about performance, > but for the first this little overhead might be justified if it enables us > to more easely port applications. Think further. Without the vision that such applications will then be also used, the whole porting enterprise is useless. Holger -- Please update your tables to my new e-mail address: holger.veit$ais.fhg.de (replace the '$' with ' at ' -- spam-protection) **= Email 15 ==========================** Date: Tue, 18 Feb 2003 21:31:07 +0100 (CET) From: "Adrian Gschwend" Subject: Re: PTHREADS On Sat, 15 Feb 2003 12:25:10 +0000, John Poltorak wrote: >There are a couple of files, but the archives are corrupt. > >I'd particularly like to get a good version of this one:- > >ftp://ftp.netlabs.org/pub/pthreads/pthread-bjs-src.zip > >Anyone know who BJS is? I assume that is the author. brian smith again :-) nuke on #netlabs (irc server: irc.anduin.net). As I said many times, IRC is a good place to meet OS/2 developers :)) is the archive really broken? Brian and Antoni T. Curtis worked on that but Antony is mainly on Linux now (btw he has the idea to bring PM API to X, also interesting :) cu Adrian -- Adrian Gschwend at netlabs.org ktk [a t] netlabs.org ------- Free Software for OS/2 and eCS http://www.netlabs.org **= Email 16 ==========================** Date: Tue, 18 Feb 2003 21:43:53 -0500 (EST) From: "Marty" Subject: Re: ln On Tue, 18 Feb 2003 18:24:48 +0100, Holger Veit wrote: > On Tue, Feb 18, 2003 at 09:21:51AM -0500, Marty wrote: > > On Tue, 18 Feb 2003 10:24:09 +0100, Holger Veit wrote: > > > > > The nasty thing is that the above might easily be integrated in either > > > EMX or Posix/2, but the drawback is that you would have to rely on > > > the UnixOS/2 environment to have links. You won't be able to reach > > > a symlinked file with a standard OS/2 editor anymore. > > > > If it helps us get some things built without script modifications, then it has > > accomplished its goal in my mind. > > The issue is not getting something built. The existence of all the > Unix tools that are available for OS/2 already shows that this is > possible somehow. The issue isn't to get something built easier > either. The issue is to have a system named UnixOS/2 which > *can be used*. You sacrifice the future usability for an easier > life as a tool developer/porter. We don't have to sacrifice anything. If there is a more elegant solution being worked on, by all means, continue. I think that getting an interim solution in place will be a bit of a crutch for us in the meantime to help bootstrap the porting of other applications. If it works well enough for now, it won't get us into any bad habits when the real solution comes around. It's completely transparent to the developer. And for the end user, I can whip up a script to translate their fake links over to real ones when the real solution is in place. If it's too schlocky for general use (which you make a good case for), we can even disable it for finished ports. A user need never see one of these fake links on their system and we don't distribute LN for anything other than developer use. That way (addressing your other message) we don't have to explain to a user why Emacs pulls up a different file than EPM. I think I'd like to get working on this, if for no other reason than to put my new-found knowledge of how to manipulate EA's to good use. ;-) This is a stop-gap solution that I should be able to slap together with minimal effort and time. Your kernel hooks/changes, while they are the proper way with the most consistent results, sound like they will take a considerable amount of time to implement. Am I right, or are they almost ready for prime-time and my point is moot? **= Email 17 ==========================** Date: Tue, 18 Feb 2003 22:40:59 +0100 From: Andreas Buening Subject: Re: Make v3.79.1 bug? John Poltorak wrote: > > Can anyone with Make v3.79.1 try building InfoZip's UNZIP? > > The source is available here:- > > ftp://ftp.info-zip.org/pub/infozip/src/unzip550.tar.gz > > The build fails when using using this verion of Make, but works with > earlier versions. Confirmed. It fails in cmd-mode while sh-mode works fine. I should be able to upload a fix tomorrow. Thanks a lot for the detailed analysis, Stefan! Bye, Andreas -- One OS to rule them all, One OS to find them, One OS to bring them all and in the darkness bind them In the Land of Mordor where the Shadows lie.