Majid Tajamolian
1999-Jun-17 06:28 UTC
need undelete function (Jeremy, what is your idea?)
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 am a subscriber of both lists, and have seen a lot of asks for this capability as yet. SAMBA team, What is your idea? -- Cheers, M. Tajamolian Jun 17
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@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.
>> 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 am a subscriber of both lists, and have seen a lot of asks for this >capability as yet. SAMBA team, What is your idea? >This would however result in concertn about performance when this option *is* used. Also, it does not avoid a (time costly) check whenever a file is to be unlink()ed. It also does not deal with archiving versions when a file is altered/overwritten instead of deleted. I guess any sort of undelete-functionality should be toggled with a #define of some sort if performance either way is an issue. I don't think that the ease of coding is a valid argument here =). Michel.
Hello, At 05.10 18/06/99 +1000, michel@nip.nl wrote:>It also does not deal with archiving versions when a file is >altered/overwritten >instead of deleted. >I guess any sort of undelete-functionality should be toggled with a >#define of some sort if performance either way is an issue. >I don't think that the ease of coding is a valid argument here =).I think versioning problems should be delegated to a proper designed versioning filesystem like the forthcoming dtfs for Linux. A simple trashcan to be used on non versioning filesystems would be enough in Samba. Bye! -- Denis Sbragion InfoTecna Tel, Fax: +39 039 2324054 URL: http://infotecna.home.dhs.org