Undelete functionality contd.

michel at nip.nl michel at nip.nl
Tue Jun 15 20:55:36 GMT 1999

>You wrote:
>| Actually I wrote a hack for this functionality myself about a year back;
>| it was simply a matter of rewriting the unlink() routine, so that not
>| only would it keep a copy of a file before being deleted, but also
>| keep several revisions of the file.
>     In a previous life, I implemented a version of the
>     VMS-like versioned files by changing open on a non-u
>     system.  
>     I like changing unlink better, so that one could
>     subsequently say 'rm foo;1' and have it really disappear.

Actually, it was a combination of a rewritten [f][re]open() and unlink() -
a different unlink() allone would not keep older versions of files
being changed rather than deleted. It then re#define'd all calls to
[f][re]open()/unlink() in the samba code to my own routines.
I've also seen someone talking about changing this in the kernel
or libc. I believe that is where it should be - perhaps as an extention
of the filesystem. Unfortunately that doesn't help people running samba
on a non-open kernelcode box =(

> There is another person at the samba-list seems done the similar
> work as u do. maybe u can contact him....

I'm not a samba developer but am willing to re-implement this - at least
efforts should be co-ordinated. With whoem and how is this done?

> ps: my little suggestion: if we add some parameters at smb.conf like
>        protected dir = /home/share, /home/user1 ;
>        trashcan dir = /smbtrash ;

My hack simply applied to all shares that samba offered. Putting a filter
descision here makes me be concerned about performance... there is a *lot*
of file I/O =/
It also completely replicated the original (native filesystem) path relative 
to the "trashcan" directory; a win95/98-like trashcan only holds the files...
Which is better? Also note that unless explicitely restored, all sorts
fstat() info of a file gets messed up because of this (access times,
modify times and what have you).

Hmm... I'm sorry if this all is beyond the scope of this list. I get
carried away easily.


More information about the samba mailing list