trn@aplcomm.jhuapl.edu (Tony Nardo) (11/22/88)
In article <6521@galbp.LBP.HARRIS.COM> mhw@wittsend.UUCP (Michael H. Warfield (Mike)) writes: >In article <8927@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >>In article <2470@aplcomm.jhuapl.edu> trn%warper.jhuapl.edu@aplvax.jhuapl.edu (Tony Nardo) writes: >>>A pity the implementers of UNIX didn't borrow one the idea of having a >>>separate "delete" bit. It's one of a number of DEC features I miss. > >>What in the world would it MEAN? It is the DIRECTORY that is modified >>by an unlink, not the inode. Would a "delete" bit then mean that no >>links to the inode could be removed? Think about the consequences for >>a bit. It would be horrible! > > Nope. Sound great as long as it was in addition to directory permissions >and not instead of directory permissions. Doesn't sound too good when you >say you will allow or disallow delete permission on all the files in a directory >regardless of the nature of the individual files. Maybe some of the definition >needs refining but it sure could fix more problems than it casues! Thank you, Michael. I was going to say the same thing, but not so briefly. unlink() would admittedly have to perform the grueling :-) task of seeing if the proper "d" permissive was set for the file. If it isn't set, you can't unlink it. "rm" would then need to report that a file could not be unlinked (or ask the user to override, in which case it has to mask in the proper "d" bit). It is rather inconsistent to allow file-dependent permissives for reading, writing, and execution but NOT for file deletion. Sheesh. What was so hard about implementing -rwxdr---r--- instead of -rwx-r--r-- for the file permissives? Too late now... ============================================================================== ARPA, BITNET: trn@aplcomm.jhuapl.edu UUCP: {backbone!}mimsy!aplcomm!trn 50% of my opinions are claimed by various federal, state and local governments. The other 50% are mine to dispense with as I see fit. ==============================================================================
gwyn@smoke.BRL.MIL (Doug Gwyn ) (11/24/88)
>>In article <8927@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >>>What in the world would it MEAN? It is the DIRECTORY that is modified >>>by an unlink, not the inode. Would a "delete" bit then mean that no >>>links to the inode could be removed? Think about the consequences for >>>a bit. It would be horrible! Well, I should have known that people wouldn't think about it just because I asked them to. I stand by my comments. Would it help if I offered a prize to the first person (other than at Bell Labs) to explain what problem such a feature would cause? P.S. Consider this in conjunction with my discussion of the 2-level design of the UNIX file system. P.P.S. Am I really the only person who USES multiple links?
greywolf@unisoft.UUCP (The Grey Wolf) (11/29/88)
In article <8974@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >>>In article <8927@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >>>>What in the world would it MEAN? It is the DIRECTORY that is modified >>>>by an unlink, not the inode. Would a "delete" bit then mean that no >>>>links to the inode could be removed? Think about the consequences for >>>>a bit. It would be horrible! > >Well, I should have known that people wouldn't think about it just >because I asked them to. > >I stand by my comments. Would it help if I offered a prize to the >first person (other than at Bell Labs) to explain what problem such >a feature would cause? For starters, there is the compatibility issue - the delete bit would invariably take some other bit in the mode word that is already in use (I don't think we have enough bits left in the mode word for three more flag bits; as I am not looking at <sys/inode.h> right now, I can't be sure). Said file structure would look pretttttty damned munged to some other machine's concept of the same thing. Secondly, it IS a property of the directory and not the file. This is part of the reason that directories have such things as write per- mission: if you could delete a file, why would you not have the right to CREATE a file...? That would not make very much sense to the average user (besides which, if you REALLY wanted to do that, you could always enforce quotas...:-) :-)). Besides which, this wouldn't really cure the rm problem. (aside: looking at the original topic concerning problems with "rm", it is my deduction and opinion that if anyone can find a way to handle it on their own (same with >, >>, dd and mv), do so. That is the beauty of the UNIX system - there is always more than one way to do something. It is not, however, their prerogative to impinge on others to do the same thing they are doing ("My way is better than your way" is an opinion and subject to change, opinion and being ignored).) > >P.P.S. Am I really the only person who USES multiple links? Emphatically, NO! I use them all the time - it saves me space in some of my bundled programs! Interesting note: D'jever notice that, in a sticky directory (void where prohibited :-)) you can make a hard link from one file to another, but if someone else owns that file, you can't remove the link you created? This seems rather strange to me, but, given the semantics of the sticky bit at this time, it follows its description to the letter. So how'd I do...? ...TheysaidDoyouseethebiggreenglowinthedarkhouseuponthehill?andIsaidYesIseethebiggreenglowinthedarkhouseuponthehillTheresabigdarkforestbetweenmeandthebiggreenglowinthedarkhouseuponthehillandalittleoldladyonaHoovervacuumcleanersayingIllgetyoumyprettyandyourlittledogTototoo I don't even *HAVE* a dog Toto... (...!{sun,ucbvax,pixar,uunet,well}!unisoft!greywolf) ...greywolf@unisoft.uu.net -- ...TheysaidDoyouseethebiggreenglowinthedarkhouseuponthehill?andIsaidYesIseethebiggreenglowinthedarkhouseuponthehillTheresabigdarkforestbetweenmeandthebiggreenglowinthedarkhouseuponthehillandalittleoldladyonaHoovervacuumcleanersayingIllgetyoumyprettyandyourlittledogTototoo I don't even *HAVE* a dog Toto...