Date: Wed, 25 Sep 2002 13:26:26 -0500 From: Dan Nelson <dnelson@allantgroup.com> To: Terry Lambert <tlambert2@mindspring.com> Cc: Julian Stacey <jhs@berklix.com>, Paolo Pisati <p.pisati@oltrelinux.com>, freebsd-hackers@FreeBSD.ORG Subject: Re: Hey, is there space for a newbie? =) Message-ID: <20020925182626.GG16302@dan.emsphone.com> In-Reply-To: <3D91EF7A.EF4918C@mindspring.com> References: <20020924175642.GB87963@southcross.skynet.org> <200209250958.g8P9wXE10208@flip.jhs.private> <20020925151358.GD16302@dan.emsphone.com> <3D91EF7A.EF4918C@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In the last episode (Sep 25), Terry Lambert said: > Dan Nelson wrote: > > You might be able to misuse the Whiteout file type in FFS to > > present a similar user interface. unlink(2) would rename the file > > to filename.timestamp and whiteoute it. ls -W, rm -W, and rm would > > list, salvage, and purge, respectively. Since S_IFWHT is a > > filetype, you would have to only allow file deletion, or encode the > > original filetype somewhere else. > > > > Alternatively, you could add a file flag equivalent to whiteout. > > "Invisible" or something, and use chflags to salvage. > > As the author of NXFS (The NetWare for UNIX extended File System) > for Novell in 1993/1994, I can say that things are a little more > complicated than that, when it comes to undelete. > > The NetWare undelete functionality, in particular, the ability to > delete multiple files of the same name, required that globbing > take place in the kernel, and that the "deleted" files be marked > not only in the inode, but in the directory space as well. The > ability to support hard links is particularly problematic, as is > the ability to recover a particular version of the file. That's why I included a rename operation as part of unlink(2). :) That way there's no globbing problem. I knew duplicated filenames would cause problems, and timestamping the filenames makes it easy for the user to pick which one they want to restore. It's up to the implementor to decide whether undelete(2) automatically renames the file back to the original, I guess. NSS's implementation is really neat, btw. Deleted files in deleted directories stay where they are, instead of moving to DELETED.SAV. All that's missing is a "salvage everything deleted between T1 and T2" command to allow your to recover from rm -rf's. > The low-space-purge facility is also exhorbitantly expensive, unless > you can maintain parent pointers for all files, so that you can > traverse the entire non-free inode list, and make a decision that > way, and then *delete by inode number*. This basically means that Yes; I can't think of an easy way around this. Parents for all files, or just deleted ones? How did NWFS do it? -- Dan Nelson dnelson@allantgroup.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020925182626.GG16302>