A solution would be to implement a VFS module that adds the file to the
veto files list.
Laterally, that would enable the file to appear deleted, but you have a
record (in smb.conf) of what file is meant to be deleted.
A suggestion, of course, but without the Recycle Bin, I think this might be
a good lateral solution.
At 01:23 PM 6/19/02 +0200, C.Lee Taylor wrote:>Greetings ...
>
> I have been give the task of either finding a way to stop people
> from deleting files from our Samba network, or as I suggest that would be
> less problematic, would be to log deletion requests.
>
> I know of the "Samba Recycle Bin" which I will be
implimenting
> with the Samba 2.2.5 release which is just round the corner, but I was
> hoping that I might be able to impliment a logging system of what files
> were modified and delete and maybe more. I was think that should not be
> a big thing to impliment in a VFS module and will be looking into this,
> but Samba 2.2 does not casade VFS modules, so I would have to do this
> Samba Head, which I am not happy about doing, because I am alread getting
> trouble because Linux is the unknow in all of this.
>
> I don't wish to change to M$ product for my server and believe
> that we can do better with an Open Source Product, but without proof that
> the Linux box is not the problem, but the users are. I am looking a
> solution that would give me something close to Netwares salvage or more
> the logging so that I can proof that a user deleted the files and not
> some ghost.
>
> If anybody has a suggestion, please let me know. Thanks.
>
>Mailed
>Lee
>
>P.S. You can't do an undelete on ext3, so that is out of the question.
>
>
>--
>To unsubscribe from this list go to the following URL and read the
>instructions: http://lists.samba.org/mailman/listinfo/samba
--------------
Martyn Ranyard
I am not a member of the samba team,
and anything that I say may not be as
accurate as a response from one of the
team. I reply to save those more
qualified time, which can more usefully
be spent developing SAMBA further.