boily@phy.ulaval.ca (Edouard Boily) (12/31/90)
Hi, Here is what I think a problem with a new command of Workbench 2.0. Let's suppose you're in a directory, say "ram:t". If you make a link with the following command "makelink .. /", it will be impossible to backup the link directory you've just made. All the backup utilities I tried crashed (I tried Quaterback 4.2, BRU which come with 2.0, Back-Pac which was distributed by C= Canada to Canadians developpers). Typically, the backup utilities mentioned get in an infifite loop when they encountered those links. Considering the behavior of backups utilities with those files, how do you backup your files. I can't believe I'm the first one wanting to backup a hard disk which contains links. Another thing, why are those links showed as simple directories and not as what they really are. When I do a list command, I should not see .. Dir ----rwed Today 23:23:17 Command-00-T01 6 ----rwed Today 23:23:05 1 file - 1 directory - 4 blocks used but I should see .. --> Ram Disk: Link l---rwed Today 23:23:17 Command-00-T01 6 ----rwed Today 23:23:05 1 file - 1 link - 4 blocks used or something like that... Any comments? - Edouard .---------------------------------------------------------. | boily@phy.ulaval.ca 1150055@LAVALVX1.bitnet | |---------------------------------------------------------| | Edouard Boily | Projects: AmiGraph, AmigIRAF, A.I.R.P. | | Physic's Dept. | Interests: Astronomy, Comp. Sciences | | Laval Univ. | Work: On my Ph. D. _ // | | Quebec, CANADA | Citation: Not yet! \X/ | `---------------------------------------------------------'
navas@cory.Berkeley.EDU (David C. Navas) (01/03/91)
In article <40262@nigel.ee.udel.edu> boily@phy.ulaval.ca (Edouard Boily) writes: > Let's suppose you're in a directory, say "ram:t". If you make >a link with the following command "makelink .. /", it will be >impossible to backup the link directory you've just made. All the Ack, be quiet or we'll never get hardlinks :) :) But seriously, read on... > Typically, the backup utilities mentioned get in an infifite >loop when they encountered those links. Right, that's because... > Another thing, why are those links showed as simple >directories and not as what they really are. When I do a list >command, I should not see > .. Dir ----rwed Today 23:23:17 >but I should see > .. --> Ram Disk: Link l---rwed Today 23:23:17 ...the links need to be invisible outside of the (filing?) system, so that they don't break every program written. Can you imagine what might happen to programs that only expected dirs or files to be getting garbage (links) instead -- insidious! That helps explain why list does what it does,, although it's certainly not the definitive answer. It also helps explain why backup programs don't work. If they (backup) don't know about links, and if the filing system never gives them any clues, then the possibility for an infinite loop -- and even incorrect restores, are possible. That's an overview of what *might* be happening -- anyone know for sure? [I'll probably read the docs tonight out of curiosity anyway...] David Navas navas@cory.berkeley.edu "Excuse my ignorance, but I've been run over by my train of thought." -me [Senior EECS major, programmer for GeoWorks, author of JazzBench] (and Calvin)
mwm@fenris.relay.pa.dec.com (Mike (My Watch Has Windows) Meyer) (01/06/91)
In article <9999@pasteur.Berkeley.EDU> navas@cory.Berkeley.EDU (David C. Navas) writes: In article <40262@nigel.ee.udel.edu> boily@phy.ulaval.ca (Edouard Boily) writes: > Let's suppose you're in a directory, say "ram:t". If you make >a link with the following command "makelink .. /", it will be >impossible to backup the link directory you've just made. All the Ack, be quiet or we'll never get hardlinks :) :) No, keep talking, so that when we do get hard links, they don't introduce serious problems (like the one you've found). > Typically, the backup utilities mentioned get in an infifite >loop when they encountered those links. The author of ExpressCopy claims that 1.5 "correctly" handles links. I haven't verified it yet (I'm still trying to read the incredibly tiny type in the update docs), but given the quality of the program, I believe him. Right, that's because... > Another thing, why are those links showed as simple >directories and not as what they really are. When I do a list >command, I should not see > .. Dir ----rwed Today 23:23:17 >but I should see > .. --> Ram Disk: Link l---rwed Today 23:23:17 ...the links need to be invisible outside of the (filing?) system, so that they don't break every program written. Can you imagine what might happen to programs that only expected dirs or files to be getting garbage (links) instead -- insidious! Yes, but - any program that asks what _type_ a file is should be told "link" for soft links (I leave it as an exercise to decide why this isn't the case for hard links). Programs that blow up when given unexpected file types are broken. List qualifies as one such program. Howver, I'd rather have the pointer on the far end of the line. That's an overview of what *might* be happening -- anyone know for sure? [I'll probably read the docs tonight out of curiosity anyway...] You've basically got it right - though your philosophy is wrong. As far as I know, there's no documented way to tell if a file is a link or not (the preceeding statement is an open invitation to flame me in public, just so long as you _tell me_ that documented by CBM method!). The author of ExpressCopy poked around inside the file system to find a heuristic that worked. This may fail in the future, but is better than never working now. <mike --
navas@cory.Berkeley.EDU (David C. Navas) (01/07/91)
In article <MWM.91Jan5214524@fenris.relay.pa.dec.com> mwm@fenris.relay.pa.dec.com (Mike (My Watch Has Windows) Meyer) writes: >In article <9999@pasteur.Berkeley.EDU> navas@cory.Berkeley.EDU (David C. Navas) writes: > > ...the links need to be invisible outside of the (filing?) system, so that > they don't break every program written. > >Yes, but - any program that asks what _type_ a file is should be told >"link" for soft links Agreed, except there are other non-"technical" reasons why this may not be feasible. Given the fact that the DOS has never been really, well, straight- forward, it's my guess that at least 90% of the software I use is written incorrectly. Fer instance, nearly every "program" I know of needs a file- selector, and as this was never provided by Cmdre, each and every program I have has a different one. How many of these can handle link-type files? So the question to mass-marketing folks (like Cmdre) is, "do we support a filetype that will be used by 10% of our market and that will break 90% of our software base?" > That's an overview of what *might* be happening -- anyone know for sure? > [I'll probably read the docs tonight out of curiosity anyway...] Never did, oh well. Didn't find it in my perusal of the DOS AutoDocs though... >You've basically got it right - though your philosophy is wrong. As >far as I know, there's no documented way to tell if a file is a link This is true (I think), and this is bad -- but the problem has non-trivial side- effects. On another thread you'll note discussion about harddrive integrity. Can you imagine the outcry if dPaint crashed whenever you looked in your /bin directory? I agree wholeheartedly that such programs are broken, but they are also prolific. >This may fail in the future, but is better >than never working now. What was that about flawed philosophies? If a program works now, and doesn't work later because it broke the rules, then that program is flawed -- this goes for programs that don't understand link types just as surely as it goes for DiskBackup copiers. The relative merits of the programs are, of course, left up to the individual consumers (that was a disclaimer... :)) > <mike As long as I have your attention Mike, I couldn't get through to your e-mail node, so I'll pass this along. I'm willing to learn any part of the new 2.0 system (except iffparse and boopsie) and bring some kind of talk to Badge about it. If you're interested after listening to my idiotic 5:30AM blathering. :) E-mail to navas@cory.berkeley.edu -- I'll be back from NY on Jan 19, so it'll have to wait till February. David Navas navas@cory.berkeley.edu "Excuse my ignorance, but I've been run over by my train of thought." -me [Senior EECS major, programmer for GeoWorks, author of JazzBench] (and Calvin)
rjc@wookumz.ai.mit.edu (Ray Cromwell) (01/08/91)
TO tell links apart from other files, how about using one of the
protection bits. So a link would look like
Things 0 6Jan90 Link ---lrwed
^
Internally this would look and act like a directory, but smart
programs could tell the difference by looking at the bit fields on the file.
Just a thought.barrett@jhunix.HCF.JHU.EDU (Dan Barrett) (01/08/91)
In article <1991Jan7.213909.12776@mintaka.lcs.mit.edu> rjc@wookumz.ai.mit.edu (Ray Cromwell) writes: > TO tell links apart from other files, how about using one of the >protection bits. So a link would look like > Things 0 6Jan90 Link ---lrwed It's concise, but inconsistent. All the other protection bits can be changed with the "protect" command, but what would 1> protect myFile +L mean??? Since links have nothing to do with file protections, this is perhaps not a good place for link information. Dan //////////////////////////////////////\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ | Dan Barrett, Department of Computer Science Johns Hopkins University | | INTERNET: barrett@cs.jhu.edu | | | COMPUSERVE: >internet:barrett@cs.jhu.edu | UUCP: barrett@jhunix.UUCP | \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\/////////////////////////////////////
jdutka@wpi.WPI.EDU (John Dutka) (01/11/91)
In article <7304@jhunix.HCF.JHU.EDU> barrett@jhunix.HCF.JHU.EDU (Dan Barrett) writes: >mean??? Since links have nothing to do with file protections, this is >perhaps not a good place for link information. That's the way it's listed in UNIX, isn't it? If I remember correctly from the last time I took a look at one of these files (last night) - this type of info is listed with the protection codes in UNIX when you ls -al. -- | husc6!m2c!wpi!jdutka | "Hey, baby - wanna do some HEAT TRANSFER? | | jdutka@wpi.wpi.edu | Heh, heh, heh!" | | John Dutka, Jr. | -Mechanical Engineers On The Prowl |
gregg@cbnewsc.att.com (gregg.g.wonderly) (01/15/91)
From article <2866@dsacg3.dsac.dla.mil>, by nfs1675@dsacg3.dsac.dla.mil ( Michael S Figg): > In article <7304@jhunix.HCF.JHU.EDU>, barrett@jhunix.HCF.JHU.EDU (Dan Barrett) writes: >> Since links have nothing to do with file protections, this is >> perhaps not a good place for link information. > > I agree that this is inconsistent, but is it anymore so than the first > position of the UNIX permissions, which shows whether the entry is a file, > directory, etc. I don't of anyway you can change this first position with > the 'chmod' command, besides the fact that it probably isn't real kosher to > change files to directorys, or directorys to files. I have little experience > with links in the UNIX environment, and don't have an A3000 or WB2.0 but > would guess that a flag could be used just like the directory is marked in > UNIX. The implementation details are what drives the output of the UN*X ls(1) output. The inode (every file/directory is an inode) contains a value called "mode". Mode has, besides the protections, the other flag type values, specifically, S_IFDIR, S_IFBLK, S_IFCHR etc which are the more special types of inodes. Another field contains the link count, which is one for most files, and two for most directories (hopefully all). The link count refers to the number of directory entries which contain this inode number. That is, doing a 'od -cx .' on a particular directory (under SYSV) yields $ od -xc 0000000 26d0 2e00 0000 0000 0000 0000 0000 0000 & 320 . \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 $ pwd /c/gregg $ od -xc .. # trimed to just the needed output yields 0015320 26d0 6772 6567 6700 0000 0000 0000 0000 & 320 g r e g g \0 \0 \0 \0 \0 \0 \0 \0 \0 The first 16 bits of a SYSV directory entry is the inode number. Inodes are indexed from the filesystem table directly by this number. Thus, the action of ln foo bar is to merely append a directory entry to "." which contains the same inode number as foo, and then to go into the filesystem and increment the link count. Now, it would probably not be a bad idea to say "Link", but you also need to say "Count" somewhere, so rather than say both (those that use links "know" what that number means generally), the link count suffices. -- ----- gregg.g.wonderly@att.com (AT&T bell laboratories)