Re: Drawbacks of implementing undelete entirely in user space
Miquel van Smoorenburg (miquels@cistron.nl)
Mon, 24 Jun 1996 10:45:53 +0200 (MET DST)
In article <Pine.LNX.3.93.960624004545.184G-100000@xarius.demon.co.uk>,
Darren J Moffat <darren@xarius.demon.co.uk> wrote:
>
><snip>
>> them. I think I've got things right. Anybody care to comment?
>
>Looks good to me, and works fine, well done.
>
>I've modified it a bit so that instead of calling fsuser() it checks to
>see if the ext2 undeletable flag is set on the file. It then moves the
>file to .wastebasket and removes the flag so that some user process can
>then delete it to free up space. Since the u flag is inherited from the
>parent directory setting it on user dirs and important system dirs is easy
>without having a hole partition setup for it, so that tmp files created by
>compilers et al don't get stuffed in .wastebasket
>
>I've also polished of the patch by adding a config option and help text.
>
>Maybe something better should be done about files in .wastebasket with
>duplicate names, I've left your solution of adding a version no.
How about moving the deleted file into a directory .wastebasket/XXXXX,
where XXXXX is the inode number of the directory the file was in at
the moment it was deleted. If that directory has the same permissions
as the original, you do not even need special tools to undelete or
"empty trash".. a shell script or perl script will do! Also, this works
recursively and you can restore everything if you undelete in reverse
order.
Ofcourse the directory structure under .wastbasket stays at max
1 level deep. In every directory you can then type "lsrm" and it
will just do something like
stat(&st, ".");
getmountpoint(buf, ".");
sprintf(buf2, "ls %s/.wastebasket/%d", buf, st.st_ino);
system(buf2);
Mike.
--
+ Miquel van Smoorenburg + Cistron Internet Services + Living is a |
| miquels@cistron.nl (SP6) | Independent Dutch ISP | horizontal |
+ miquels@drinkel.ow.org + http://www.cistron.nl/ + fall +