need undelete function (Jeremy, what is your idea?)

Steve Fosdick steve.fosdick at aom.bt.co.uk
Thu Jun 17 16:00:48 GMT 1999


Majid Tajamolian wrote:
 
> Hi there:
> 
> > ps: my little suggestion: if we add some parameters at smb.conf like
> >        protected dir = /home/share, /home/user1 ;
> >        trashcan dir = /smbtrash ;
> 
> It seems that implementation of such parameter has some difficulties and
> eventuates reduction on performance (e.g. handling "protected dir"s and
> "trash dir" on the different devices like /dev/hda1 & /dev/hdb1).
> I suggest a service specific parameter in smb.conf like the followings:
> 
>         remove utility = /etc/scripts/saferm
> 
> The benefits with such policy are:
> 1. The implementation in SAMBA code is much easier.
> 2. The undelete policy is fully under control of administrator
>    in a per service or global manner.
> 3. The administrator can turns off it for performance critical services.

I would imagine that implementing this feature at share level would not
only be easier but would also turn in better performance overall as it
avoids the need to compare directory pathnames against a global list
everytime a destructive operation (like unlink) is attempted.

Implementing this at share level is a little less configurable in one
respect in that the granularity of control is not quite as fine, but it
also provides extra configurability in another respect in that it
enables some users of a directory to have delete protection on and other
not depending on which share name they connect to. (assuming you have
two shares pointing to the same directory or one which is a subdirectory
of another).

Specifying an external program gives a great deal of flexibility but
will be at a cost in performance.  Forking another process and executing
another program is rather slow (relatively) and therefore deleting a
directory tree when this is done by the client issuing requests to
delete individual files and directories will become very slow.

There is also more than one destructive operation so there is the level
of functionality require to consider:

LEVEL 1: Just handle the unlink call.  This will protect against user's
accidentally deleting files from explorer and against programs deleting
files.  On it's own it will not protect against overwriting a good file
with another or bad file.

LEVEL 2: Also handle the open/creat calls that cause the previous
contents of the file to be discarded (i.e. anything with O_TRUNC set). 
An open with truncate is handle as a delete followed by creating a new,
empty file with the same name, owner, permissions etc as the previos
file.

LEVEL 3: Include file modification.  When a file is openned for write or
for read/write, the first actual write to the file causes a backup copy
to be taken before the write is applied to the file.  Only one backup
copy is taken for the time that the file is kept open.

Even if the intention is just to implement level 1 now it would be good
if the chosen mechanism was able to handle the extra functionality later
on.

As far as mechanisms for maintaining the backup copy is concerned I can
see a number of possibilities:

1.  Adopt version numbers like VMS.  In this case the backup files are
held in the same directory as the original file and just have a version
number.

2.  Backup files are put in a hidden subdirectory or the directory the
original file was in (e.g. .deleted) thus removing the need to store the
path.  The disadvantage is that it is difficult to provide a "Trash Can"
view where users can pick files for restoration.

3.  Backup files are renamed to hidden files having automatically
generated names still in the original directory.  This is the approach
NFS takes to a file that should be deleted but is still open somewhere. 
In this case a small database would be required in each directory that
contained backup files to match the generated names to the original
names.

4.  Have a central trashcan directory per share.  This can adopt one of
two naming policies:

    a.  re-create the whole path (from the top dir of the share) for
each file under the trashcan directory.

    b.  use auto-generated names in the trash can directory and a small
database to map these to the original paths.

Of these the centralised approach has the advantage that an entrie
directory can be deleted and still have the backup files.

More comments? ...
-- 
Steve Fosdick                  Internet: fosdicsj at aom.bt.co.uk
Voice: +44 1473 642987         MSMAIL:   BTEA/BTLIP23/FOSDICSJ
Fax:   +44 1473 646656         BOAT:     FOSDICSJ
Snail: B29/G34, BT Labs, Martlesham Heath, Ipswich, IP5 7RE, England.


More information about the samba mailing list