recycle.c (was block.c)

Alexander Bokovoy a.bokovoy at sam-solutions.net
Mon Sep 2 15:04:00 GMT 2002


On Mon, Sep 02, 2002 at 08:43:15PM +0200, Juergen Hasch wrote:
> Am Montag, 2. September 2002 11:03 schrieb Alexander Bokovoy:
> >
> > Seens xlc_r is stricter. Would following help xlc_r? It looks worser but
> > works fine for gcc.
> >
> > #define VFS_OP(x) ((void *) x)
> >
> > static vfs_op_tuple recycle_ops[] = {
> >
> > 	/* Disk operations */
> >
> > 	{VFS_OP(recycle_connect),	SMB_VFS_OP_CONNECT,	SMB_VFS_LAYER_OPAQUE},
> > 	{VFS_OP(recycle_disconnect),	SMB_VFS_OP_DISCONNECT,	SMB_VFS_LAYER_OPAQUE},
> >
> > 	/* File operations */
> >
> > 	{VFS_OP(recycle_unlink),	SMB_VFS_OP_UNLINK,	SMB_VFS_LAYER_OPAQUE},
> >
> > 	{NULL,			SMB_VFS_OP_NOOP,	SMB_VFS_LAYER_NOOP}
> > };
> 
> this works, the compiler doesn't complain anymore.
Ok.

2Jeremy and Andrew:
How about to make VFS_OP()-like work-around a part of standard VFS layer
coding conventions?
 
> I've updated the recycle bin to use the parametrical options inside smb.conf. 
> I think you told me at the SambaXP conference how to find out, if the service 
> is derived from [homes]. Could you tell me again ?
I promized tridge to fix this but haven't done it yet. Expect this in a
middle of September. :(

> I need to find this out or the parametrical options won't work for [homes]. 
Metze did something to fix this by specifying user names as shares. This
is a hack and I must complete parametrical options instead.

> 
> For now the options have the form:
> 
> vfs_recycle: mode = KEEP_DIRECTORIES|TOUCH
> 
> Should be clear which module they belong to :-)
Yeah :)
-- 
/ Alexander Bokovoy
---
"Pull the trigger and you're garbage."
-- Lady Blue



More information about the samba-technical mailing list