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
