mroussel@alchemy.chem.utoronto.ca (Marc Roussel) (02/18/91)
In article <453@bria> uunet!bria!mike writes: >My flame was not attacking the _concept_ of undeletion. My objection to NU >was the way that it was done (hooking onto the operating system, and munging >with calls like statfs() so that they lie about the _true_ state of things). >It's nothing but a kludge. The ability to undelete files should be a >capability of the kernel and underlying filesystem, not some external hack. AT&T hasn't done it. Berkeley's kernel doesn't support undeletion. If people want this feature, they'll obviously have to look somewhere else. >If you are an accountant (and many of the poeple that I work with are), then >your needs _are_ important to me. My job is to make sure that if something >gets in your way, I remove it. _I_ am the admin, _you_ are the end user. >I will administer, you will use. 'Nuff said. In many university departments, the lines aren't that wonderfully clear. Thankfully, in this department we can afford a sys admin and I am more than glad to let Mike to his job. A lot of departments can't afford a system administrator though, and I'm sure a lot of small businesses are like that too. Someone has to wear two hats. Unix is ideally suited to small networks and people are buying it in recognition of this fact. If however it turns out that Unix is an expensive system to run because you have to hire a system administrator (or make heavy use of consultants), Unix won't last long in the smallish systems arena. >There should be the ability for a user >to recover deleted files. My point is that it should be a function of >the kernel, and not an external kludge. > >Should I compare methodology, I would much prefer a tool that goes hunting >through the freelist and recovering only part of my file, rather than >Pete Norton sticking his fingers in my kernel. Now you're not even making sense. Norton quite reasonably implements undeletion in the kernel (through a kernel patch), the approach which you favour, and yet you object to "Norton sticking his fingers in my kernel". Sheesh! Sincerely, Marc R. Roussel mroussel@alchemy.chem.utoronto.ca
mike (02/18/91)
In an article, alchemy.chem.utoronto.ca!mroussel (Marc Roussel) writes: >In article <453@bria> uunet!bria!mike writes: >>Should I compare methodology, I would much prefer a tool that goes hunting >>through the freelist and recovering only part of my file, rather than >>Pete Norton sticking his fingers in my kernel. > >Now you're not even making sense. Norton quite reasonably implements >undeletion in the kernel (through a kernel patch), the approach which >you favour, and yet you object to "Norton sticking his fingers in my kernel". >Sheesh! I thought I made myself rather clear on this point. My objection is the fact that NU implements undeletion in the kernel by "patching" (read: molesting) it. I stated that I would like to see kernel support for file undeletion. When I say kernel support, I mean as being a fundamental part of the filesystem code, not a hack applied from the outside. I certainly did _NOT_ state that I would like to see a bunch of migrant workers from the DOS world fingering my operating system. To make it even more clear: If you are a company that ports versions of UNIX to various platforms, it would be nice to see support for file recovery at the kernel level. If you are a company that writes tools (er, toys) for MS-DOS systems, and you have an urge to mung with the OS, do us all a favor and kindly stay the hell of of the UNIX marketplace. Not that I have a prejudice against DOS, or anything like that. :-) Cheers, -- Michael Stefanik, MGI Inc., Los Angeles| Opinions stated are not even my own. Title of the week: Systems Engineer | UUCP: ...!uunet!bria!mike ------------------------------------------------------------------------------- Remember folks: If you can't flame MS-DOS, then what _can_ you flame?
mjr@hussar.dco.dec.com (Marcus J. Ranum) (02/19/91)
In article <465@bria> uunet!bria!mike writes: >I stated that I would like to see kernel support for file undeletion. The kernel (henceforth known as "the watermelon") is already bloated enough because of features being banged into it. Implement file undeletion in the application layer, and your life will be much easier. If you're going to hop up and down and be all "death to DOS" fascist, don't turn around and contradict yourself by asking for another "feeture" in UNIX. Real UNIX gurus never delete the wrong files, and even if they did, they'd just fix it with fsdb. mjr.
mike (02/20/91)
In an article, hussar.dco.dec.com!mjr (Marcus J. Ranum) writes: >In article <465@bria> uunet!bria!mike writes: > >>I stated that I would like to see kernel support for file undeletion. > > The kernel (henceforth known as "the watermelon") is already >bloated enough because of features being banged into it. Implement file >undeletion in the application layer, and your life will be much easier. I doubt that it can be done completely without any kind of kernel support. The programs that don't mung the kernel don't do a terribly great job of file recovery under heavy disk usage (which is usually the status quo). I agree that the kernel is bloated; personally, I don't think that the filesystem code should even be _part_ of the kernel in the first place. Detachable filesystem code would be a significant win: it would reduce the size of the kernel and facilitate changes such as file recovery (as well as other things, such as mounting foriegn filesystems, etc.) > If you're going to hop up and down and be all "death to DOS" >fascist, don't turn around and contradict yourself by asking for another >"feeture" in UNIX. Real UNIX gurus never delete the wrong files, and >even if they did, they'd just fix it with fsdb. Personally, I whip out my 6150 and endure the pain of the restore -- it encourages me to be more careful next time. Again, I would like to see you use fsdb to restore a file that you discover has been deleted by another user 3 hours ago, and heavy disk use has been taking place. Not terribly likely. -- Michael Stefanik, MGI Inc., Los Angeles| Opinions stated are not even my own. Title of the week: Systems Engineer | UUCP: ...!uunet!bria!mike ------------------------------------------------------------------------------- Remember folks: If you can't flame MS-DOS, then what _can_ you flame?
dag@fciva.FRANKCAP.COM (Daniel A. Graifer) (02/20/91)
In article <465@bria> uunet!bria!mike writes: >[quotation deleted] >I thought I made myself rather clear on this point. My objection is >the fact that NU implements undeletion in the kernel by "patching" >(read: molesting) it. > >I stated that I would like to see kernel support for file undeletion. >When I say kernel support, I mean as being a fundamental part of the >filesystem code, not a hack applied from the outside. I certainly did >_NOT_ state that I would like to see a bunch of migrant workers from >the DOS world fingering my operating system. >[...] >Cheers, >-- >Michael Stefanik, MGI Inc., Los Angeles| Opinions stated are not even my own. >Title of the week: Systems Engineer | UUCP: ...!uunet!bria!mike >------------------------------------------------------------------------------- >Remember folks: If you can't flame MS-DOS, then what _can_ you flame? Excuse me, but I think I sense some unwarrented assumptions here. I was under the impression that NU 'patched' the kernal by providing a replacement '.o' and '.a' files. I've seen nothing in the recent discussion here to contradict this. How else would you provide an OS level enhancement? Also, I thought I heard that Norton either hired a new team, or subcontracted the Unix version to somebody who HAD unix expertise. The Norton label may imply marketing, QA, and support only. As I see it, the standard unix filesystem divides the filesystem into two pieces: Allocated & Free. NU divides it into Allocated and May-Be-Reallocated, and provides a smart mechanism for determining the order of reuse. Free Space is still the amount of space in the later category. Besides: Relax! Nobody is asking YOU to buy it! Dan -- Daniel A. Graifer Coastal Capital Funding Corp. Sr. Vice President, Financial Systems 7900 Westpark Dr. Suite A-130 (703)821-3244 McLean, VA 22102 uunet!fciva!dag fciva.FRANKCAP.COM!dag@uunet.uu.net
tif@doorstop.austin.ibm.com (Paul Chamberlain) (02/20/91)
In article <468@bria> uunet!bria!mike writes: >Again, I would like to see >you use fsdb to restore a file that you discover has been deleted by >another user 3 hours ago, and heavy disk use has been taking place. Not >terribly likely. Not to mention new fangled systems with security that guarantee that the blocks have been "erased." This is in no way an endorsement of the Norton Utilities, I've never even used a Norton Utility and wouldn't be caught dead installing some kernel modification that creates a class of blocks called "might-be-free." Paul Chamberlain | I do NOT speak for IBM. IBM VNET: PAULCC AT AUSTIN 512/838-9662 | ...!cs.utexas.edu!ibmchs!auschs!doorstop.austin.ibm.com!tif
ac999321@umbc5.umbc.edu (ac999321) (02/27/91)
>>>If you're an accountant, then do accounting, not programming. Righto! That's why centralized computing is such a good idea; keep complete computer systems away from those who mung things up when someone from the DP department isn't looking over their shoulder; a way to prevent headaches. :-) >>You're right. I'll do the accounting or whatever, and if something >>about UNIX gets in my way, I'll go buy someone else's package to get it >>out of my way. Your disdain for my computing problems means that I >>won't buy the package from you, since you obviously don't understand my >>needs or care about them. Proves that system "users" don't really know what they need or what is best for them. Refer to the Theory of Usermungetivity for more info on this. >your needs _are_ important to me. My job is to make sure that if something >gets in your way, I remove it. _I_ am the admin, _you_ are the end user. >I will administer, you will use. 'Nuff said. here here! >>Retrieving a clobbered file is not, by definition, a job for a >>sysadmin. There's nothing privileged about it. And people want to do >I agree with this completely. There should be the ability for a user >to recover deleted files. My point is that it should be a function of >the kernel, and not an external kludge. IHMO, it seems there already is an easy way to accomplish this; write a shell script that banishes "deleted" files to a "wastbasket" directory and make the user purge the wastebasket when his storage space is used up.
art@wciu.EDU (Art Nicolaysen) (02/28/91)
In article <5163@umbc3.UMBC.EDU> ac999321@umbc5.umbc.edu.UUCP (ac999321) writes: >>>Retrieving a clobbered file is not, by definition, a job for a >>>sysadmin. There's nothing privileged about it. And people want to do >>I agree with this completely. There should be the ability for a user >>to recover deleted files. My point is that it should be a function of >>the kernel, and not an external kludge. > >IHMO, it seems there already is an easy way to accomplish this; write a >shell script that banishes "deleted" files to a "wastbasket" directory and >make the user purge the wastebasket when his storage space is used up. As long as the user isn't real close to his/her quota limit, the purge function can be accomplished every time the user logs out. I use an aliased rn (alias rn mv \!* ~/trash_dir) and two lines in a .logout file. This is not a totally robust method, however; does anybody want to post or email me their shell script? -- Art Nicolaysen William Carey Int'l University (Global Mapping) art@wciu.edu Pasadena CA 91104