dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) (09/16/89)
In all my years hacking UNIX systems I've never cared how fast
soft links are vs hard links, or hard links vs aliases, or whatever.
It simply does not matter, you don't notice the difference.
99.99999% of the time one is worrying about the billions of read() and
write() calls you need to make rather than the *one* time you need to
open the file.
Give me a break!
-Mattdavewt@NCoast.ORG (David Wright) (09/17/89)
Not only is the speed difference insignificant, but adding ANY kind of links would require changes to the operating sys. Links also have the problem of making the disk directory structure more confusing, and you can accidently squash files you didn't intend to. Say you have a link like "ln rm delete". Then you get a great rm port from unix and copy it to c: Now you just squashed your old version of delete. At least with aliases both files would exist, and you would just have to take out the alias from your startup-file... Links: just say no
addison@pollux.usc.edu (Richard Addison) (09/18/89)
In article <1989Sep17.141013.512@NCoast.ORG> davewt@ncoast.ORG (David Wright) writes: > Not only is the speed difference insignificant, but adding ANY kind of >links would require changes to the operating sys. Links also have the problem >of making the disk directory structure more confusing, and you can accidently >squash files you didn't intend to. Say you have a link like "ln rm delete". >Then you get a great rm port from unix and copy it to c: Now you just >squashed your old version of delete. At least with aliases both files would >exist, and you would just have to take out the alias from your startup-file... > > Links: just say no The behaviour you describe would probably not occur with the kind of links that could be introduced to AmigaDOS. The directory entry for "rm" would give the path name for "delete". When you copy a "great rm port from unix" to your C: directory, you would wipe out the link without replacing "delete". If you doubt this, treat the "copy src dst" operation as "delete dst", "create dst", and "copy src dst". Since AmigaDOS would have soft links, the "delete dst" operation would destroy the link. The following create operation would create a new file. Note the lack of symmetry between performing "copy GrmPFU C:rm" and performing "copy GrmPFU C:delete" when "C:rm" is soft-linked to "C:delete". A hard link would act symmetrically. But, as discussed before, adding hard links to AmigaDOS is non-trivial. Now, I suppose that the links being proposed for AmigaDOS could be soft links with hard link semantics, but I'd not prefer this. Links: Just say thanks! 1> list USENET:R#? Directory "USENET:R#?" on Sunday 17-Sep-89 Richard Addison Link ----r--- Today 14:15:16 Soft-linked to a real person. 1> endshell
dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) (09/18/89)
:
: Not only is the speed difference insignificant, but adding ANY kind of
:links would require changes to the operating sys. Links also have the problem
:of making the disk directory structure more confusing, and you can accidently
:squash files you didn't intend to. Say you have a link like "ln rm delete".
:Then you get a great rm port from unix and copy it to c: Now you just
:squashed your old version of delete. At least with aliases both files would
:exist, and you would just have to take out the alias from your startup-file...
:
: Links: just say no
Oh *Please*, lets not argue about simple semantics. The obvious
solution is to have ln refuse to overwrite a file, which makes ln
harmless, eh?
-Mattdavewt@NCoast.ORG (David Wright) (09/19/89)
Well, that IS the obvious way, but it still requires that the OS be patched to handle links, which is just another place for a bug to creep in. And for a fairly unimportant feature at that...
shadow@pawl.rpi.edu (Deven T. Corzine) (09/19/89)
On 16 Sep 89 01:28:44 GMT, dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) said: Matt> In all my years hacking UNIX systems I've never cared how fast Matt> soft links are vs hard links, or hard links vs aliases, or Matt> whatever. Matt> It simply does not matter, you don't notice the difference. Matt> 99.99999% of the time one is worrying about the billions of Matt> read() and write() calls you need to make rather than the *one* Matt> time you need to open the file. Normally, the difference IS negligable. The exceptions come when you get many layers of symbolic links, on the 386i, for example... Deven -- Deven T. Corzine Internet: deven@rpi.edu, shadow@pawl.rpi.edu Snail: 2151 12th St. Apt. 4, Troy, NY 12180 Phone: (---) --none-- Bitnet: deven@rpitsmts, userfxb6@rpitsmts UUCP: uunet!rpi!deven Simple things should be simple and complex things should be possible.
esker@abaa.uucp (Lawrence Esker) (09/20/89)
In article <1989Sep18.210925.5543@NCoast.ORG> davewt@ncoast.ORG (David Wright) writes: > Well, that IS the obvious way, but it still requires that the OS >be patched to handle links, which is just another place for a bug to >creep in. And for a fairly unimportant feature at that... I have never used many of the system calls (like maybe OpendiskFont()) and probably never will. Am I allowed to say they are "fairly unimportant features"? The whole attractive power of the Amiga is its open architecture and features for everyone. Links may be unimportant to you, but that is NEVER a reason to not include it in the Amiga. I have tried on several occasions to add link support of any kind but just never had enough knowledge of AmigaDOS to patch it. So I've given up. P.S. I've changed your keywords to "Links are good". -- ---------- Lawrence W. Esker ---------- Modern Amish: Thou shalt not need any computer that is not IBM compatible. UseNet Path: __!mailrus!sharkey!itivax!abaa!esker == esker@abaa.UUCP
mwm@eris.berkeley.edu (Mike (I'll think of something yet) Meyer) (09/22/89)
In article <1989Sep18.210925.5543@NCoast.ORG> davewt@ncoast.ORG (David Wright) writes: > Well, that IS the obvious way, but it still requires that the OS >be patched to handle links, which is just another place for a bug to >creep in. And for a fairly unimportant feature at that... Gee, people were telling me what great stuff ARP was, because it saved - what, 40 or 50K? As a conservative estimate, links would save me ~400K on a single project. From that perspective, links are an order of magnitude more important than getting an ARP-like facilitiy into 1.4. <mike -- Es brillig war. Die schlichte Toven Mike Meyer Wirrten und wimmelten in Waben; mwm@berkeley.edu Und aller-mumsige Burggoven ucbvax!mwm Die mohmem Rath' ausgraben. mwm@ucbjade.BITNET
lphillips@lpami.wimsey.bc.ca (Larry Phillips) (09/22/89)
In <22444@cup.portal.com>, FelineGrace@cup.portal.com (Dana B Bourgeois) writes: >Count me as one of the people who would like to see links available in >1.4 as part of the operating system. And I would be grateful to the >person who releases a program(library, patch, whatever: I'm not picky!) >that allows links in 1.3. I have thought of several projects that would >benefit mightily from links, either soft or hard. Does anyone have >links installed in their systems? Can they release the software? Please? A friend and I have been chatting about this for a couple of weeks now, nothing in depth, but just sort of batting around some ideas. We figure we can imlement links on the current system in a rather kludgy way by using SetFunction() (or whatever it will take for dos.library) to patch/replace those functions that will have to be aware of links. We were figuring that it would be a 'proof of concept', and that any serious use of links would await 1.4 These would be hard links, on files only, with each file header block pointing to the first data block. So far, here are the system things we know we have to patch/replace. If anyone can think of any others that would need patching/replacing, please feel free to speak up. Close() DeleteFile() Lock() Open() UnLock() And last, but not least, the disk-validator (I have been wanting to rewrite this one ever since I got my first "key already set" error). -larry -- The Mac? Oh, that's just like a computer, only slower. +-----------------------------------------------------------------------+ | // Larry Phillips | | \X/ lphillips@lpami.wimsey.bc.ca -or- uunet!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 -or- 76703.4322@compuserve.com | +-----------------------------------------------------------------------+
ain@mentor.cc.purdue.edu (Pat-bob White) (09/23/89)
In article <1989Sep18.210925.5543@NCoast.ORG> davewt@ncoast.ORG (David Wright) writes: >And for a fairly unimportant feature at that... Actually, the feature *can* save you lots of disk space. eg: compress. Compress, uncompress, and zcat all use enough of the same code that they are designed to look at argv[0] and decide how to act. The additional code to do the check and make the change in operation was far less than two more copies of the program would be. (BTW, even the Amiga version of compress that was ported from unix still does this.) So, soft links (or a shell that does "aliases" a certain way), would suffice for getting three separate prorgams from one. (a shell would have to pass the aliased name as argv[0] to the program.. not difficult) I know one could just add options to the program to control its functioning, but sometimes it is nice to just be able to type "zcat foo.Z" rather than "compress -dc foo.Z". Pat White ARPA/UUCP: j.cc.purdue.edu!ain BITNET: PATWHITE@PURCCVM PHONE: (317) 743-8421 U.S. Mail: 320 Brown St. apt. 406, West Lafayette, IN 47906 Did you ever feel like you were living in a hierarchy?
FelineGrace@cup.portal.com (Dana B Bourgeois) (09/23/89)
Count me as one of the people who would like to see links available in 1.4 as part of the operating system. And I would be grateful to the person who releases a program(library, patch, whatever: I'm not picky!) that allows links in 1.3. I have thought of several projects that would benefit mightily from links, either soft or hard. Does anyone have links installed in their systems? Can they release the software? Please? Dana
wfh58@leah.Albany.Edu (William F. Hammond) (09/24/89)
In article <4174@mentor.cc.purdue.edu>, ain@mentor.cc.purdue.edu (Pat-bob White) writes: > ... > Actually, the feature *can* save you lots of disk space. eg: compress. > Compress, uncompress, and zcat all use enough of the same code that > they are designed to look at argv[0] and decide how to act. The additional > code to do the check and make the change in operation was far less than two > more copies of the program would be. (BTW, even the Amiga version of > compress that was ported from unix still does this.) > So, soft links (or a shell that does "aliases" a certain way), would > suffice for getting three separate prorgams from one. (a shell would have to > pass the aliased name as argv[0] to the program.. not difficult) > I know one could just add options to the program to control its > functioning, but sometimes it is nice to just be able to type "zcat foo.Z" > rather than "compress -dc foo.Z". > > Pat White > ARPA/UUCP: j.cc.purdue.edu!ain BITNET: PATWHITE@PURCCVM PHONE: (317) 743-8421 > U.S. Mail: 320 Brown St. apt. 406, West Lafayette, IN 47906 ******************************************************************************* The trouble with programs whose behavior depends on (a) the command line entry or (b) the filename is that they are a bit tricky for an environment that is as "uncontrolled" as the Amiga's. There is too much risk of my wanting to have two different but closely related programs from different authors around at the same time with "naming" conflicts for me to be happy with behavior that depends on a hard-coded name. For example, there was a period earlier this year when I found myself wanting to have two different versions of "execute" handy. If our concern is with redundant code in the "system", we should use libraries. (What a magnificent job of squeezing the library concept for all it's worth has been done in ARP 1.3!) (In a sense one can think of the ARP commands as being "links".) And if it's too much trouble to type "compress -dc foo.Z" , then we type once "alias zcat compress -dc " . P.S. "argv[0]" *ought* to be the filename rather than the command line entry. ------------------------------------------------------------------------ William F. Hammond Dept. of Mathematics & Statistics 518-442-4625 SUNYA wfh58@leah.albany.edu Albany, NY 12222 -------------------------------------------------------------------------
FelineGrace@cup.portal.com (Dana B Bourgeois) (09/26/89)
::Commenting on stuff about which I know very little:: If you must rewrite the lock() function, wouldn't you need to rewrite the duplock() function also? Dana "I know, my ignorance is showing" Bourgeois
FelineGrace@cup.portal.com (Dana B Bourgeois) (09/26/89)
::Watch out!! Beginner at work!!::
"Argv[0] should be the filename..."
^^^^^^^^^
My volume of K&R C second edition says on page 115 that BY CONVENTION
argv[0] is the command name. Now I know it said convention but if
the amiga community is gonna change the convention then maybe we all
better vote on it somehow.
I know I'll vote for links and sticking with the convention.
Dana Bourgeois