Add new RECALL_OFFLINE vfs function

To be used for recalling files migrated to offline storage by a
Hierarchical Storage Management system.

| 6
source/include/vfs.h | 4
source/include/vfs_macros.h | 3
source/modules/vfs_default.c | 16
4 files changed, 26 insertions(+), 3 deletions(-)

diff
index ea8530dc5d1a65 100644


@@ -548,11 +548,12 @@ static int skel_set_offline(struct vfs_handle_struct *handle, const char *path)
return SMB_VFS_NEXT_SETFFLINE(handle, path);
}

-static bool skel_is_remotestorage(struct vfs_handle_struct *handle, const char *path)
+static int skel_recall_offline(struct vfs_handle_struct *handle, struct files_struct *fsp)
{
- return SMB_VFS_NEXT_IS_REMTESTRAGE(handle, path);
+ return SMB_VFS_NEXT_RECALLFFLINE(handle, fsp);
}

+
/* VFS operations structure */

static vfs_op_tuple skel_op_tuples[] = {
@@ -674,6 +675,7 @@ static vfs_op_tuple skel_op_tuples[] = {
/* offline operations */
{SMB_VFSP(skel_is_offline), SMB_VFSP_ISFFLINE, SMB_VFS_LAYER_TRANSPARENT},
{SMB_VFSP(skel_set_offline), SMB_VFSP_SETFFLINE, SMB_VFS_LAYER_TRANSPARENT},
+ {SMB_VFSP(skel_recall_offline), SMB_VFSP_RECALLFFLINE, SMB_VFS_LAYER_TRANSPARENT},

{NULL, SMB_VFSP_NP, SMB_VFS_LAYER_NP}
};
diff a/source/include/vfs.h b/source/include/vfs.h
index 9b72f696500c58 100644
a/source/include/vfs.h
b/source/include/vfs.h
@@ -108,6 +108,7 @@
/* Leave at 22 - not yet released. Remove parameter fd from close_fn. - obnox */
/* Changed to version 23 - remove set_nt_acl call. This can only be done via an
open handle. JRA. */
+/* Leave at 23 - not yet released. Add recall_offline for offline files */

#define SMB_VFS_INTERFACE_VERSIN 23

@@ -266,6 +267,7 @@ typedef enum _vfs_op_type {
/* offline operations */
SMB_VFSP_ISFFLINE,
SMB_VFSP_SETFFLINE,
+ SMB_VFSP_RECALLFFLINE,

/* This should always be last enum value */

@@ -422,6 +424,7 @@ struct vfs_ops {
/* offline operations */
bool (*is_offline)(struct vfs_handle_struct *handle, const char *path, SMB_STRUCT_STAT *sbuf);
int (*set_offline)(struct vfs_handle_struct *handle, const char *path);
+ int (*recall_offline)(struct vfs_handle_struct *handle, struct files_struct *fsp);
} ops;

struct vfs_handles_pointers {
@@ -548,6 +551,7 @@ struct vfs_ops {
/* offline operations */
struct vfs_handle_struct *is_offline;
struct vfs_handle_struct *set_offline;
+ struct vfs_handle_struct *recall_offline;
} handles;
};

diff a/source/include/vfs_macros.h b/source/include/vfs_macros.h
index 7b3aeaac5bf386 100644
a/source/include/vfs_macros.h
b/source/include/vfs_macros.h
@@ -144,6 +144,7 @@
/* operations */
#define SMB_VFS_ISFFLINE(conn,path,sbuf) ((conn)->vfs.ops.is_offline((conn)->vfs.handles.is_offline,(path),(sbuf)))
#define SMB_VFS_SETFFLINE(conn,path) ((conn)->vfs.ops.set_offline((conn)->vfs.handles.set_offline,(path)))
+#define SMB_VFS_RECALLFFLINE(fsp) ((fsp)->conn->vfs.ops.recall_offline((fsp)->conn->vfs.handles.recall_offline,(fsp)))

/
Don't access conn->vfs_opaque.ops directly!!!
@@ -269,6 +270,7 @@
/* operations */
#define SMB_VFSPAQUE_ISFFLINE(conn,path,sbuf) ((conn)->vfs_opaque.ops.is_offline((conn)->vfs_opaque.handles.is_offline,(path),(sbuf)))
#define SMB_VFSPAQUE_SETFFLINE(conn,path) ((conn)->vfs_opaque.ops.set_offline((conn)->vfs_opaque.handles.set_offline,(path)))
+#define SMB_VFSPAQUE_RECALLFFLINE(fsp) ((fsp)->conn->vfs_opaque.ops.recall_offline((fsp)->conn->,(fsp)))

/
Don't access handle->vfs_next.ops.* directly!!!
@@ -395,5 +397,6 @@
/* operations */
#define SMB_VFS_NEXT_ISFFLINE(handle,path,sbuf) ((handle)->vfs_next.ops.is_offline((handle)->vfs_next.handles.is_offline,(path),(sbuf)))
#define SMB_VFS_NEXT_SETFFLINE(handle,path) ((handle)->vfs_next.ops.set_offline((handle)->vfs_next.handles.set_offline,(path)))
+#define SMB_VFS_NEXT_RECALLFFLINE(handle,fsp) ((handle)->vfs_next.ops.recall_offline((handle)->,(fsp)))

#endif /* _VFS_MACRS_H */
diff a/source/modules/vfs_default.c b/source/modules/vfs_default.c
index 6ee677ec6c450c 100644
a/source/modules/vfs_default.c
b/source/modules/vfs_default.c
@@ -1311,6 +1311,18 @@ static int vfswrap_set_offline(struct vfs_handle_struct *handle, const char *pat
return -1;
}

+static int vfswrap_recall_offline(struct vfs_handle_struct *handle, struct files_struct *fsp)
+{
+ /*
+ * We don't know how to recall an offline file by default, needs to be
+ * overriden in other vfs modules
+ */
+#if defined(ENTSUP)
+ errno = ENTSUP;
+#endif
+ return -1;
+}
+
static vfs_op_tuple vfs_default_ops[] = {

/* Disk operations */
@@ -1529,7 +1541,6 @@ static vfs_op_tuple vfs_default_ops[] = {
SMB_VFS_LAYERPAQUE},
{SMB_VFSP(vfswrap_aio_suspend),SMB_VFSP_AISUSPEND,
SMB_VFS_LAYERPAQUE},
-
{SMB_VFSP(vfswrap_aio_force), SMB_VFSP_AIFRCE,
SMB_VFS_LAYERPAQUE},

@@ -1537,6 +1548,9 @@ static vfs_op_tuple vfs_default_ops[] = {
SMB_VFS_LAYERPAQUE},
{SMB_VFSP(vfswrap_set_offline),SMB_VFSP_SETFFLINE,
SMB_VFS_LAYERPAQUE},
+ {SMB_VFSP(vfswrap_recall_offline),SMB_VFSP_RECALLF FLINE,
+ SMB_VFS_LAYERPAQUE},
+

/* Finish VFS operations definition */

--
1.5.4.rc0

Fri, Jun 13, 2008 at 06:19:09PM +1000, David Disseldorp wrote:
send_nt_replies currently sets SetupCount to zero, however some packets
require different values. When testing FSCTL_RECALL_FILE, Windows XPsp2
was observed dropping connections where SetupCount was not one in the server
response.

The SNIA CIFS documentation also describes NT_TRANSACT_ICTL server response
packets as having a SetupCount of 1.

Looking at send_nt_replies I've got some points:

First a purely stylistic, trivial one: We're trying to
standardize on uint16_t, not uint16 these days. For new code
that should be the the one to use.

Then another stylistic one: The do {} while variant of a
loop is a bit cumbersome to read. Can we turn that into the
old form again?

And then a real question: You seem to send the setup
portion of the reply in every partial nttrans reply packet.
Is that the right way to do? I don't know how to trigger
that with Windows, but it looks wrong to me.

Volker

PGP SIGNATURE
Version: GnuPG v1.4.5 (GNU/Linux)


oUe4i7scTrdnZlVZoIgcaDg=
=dyzC
PGP SIGNATURE

Mon, Jun 23, 2008 at 11:21:44AM +1000, David Disseldorp wrote:
First a purely stylistic, trivial one: We're trying to
standardize on uint16_t, not uint16 these days. For new code
that should be the the one to use.

Then another stylistic one: The do {} while variant of a
loop is a bit cumbersome to read. Can we turn that into the
old form again?

No problems, i'll change the areas above.

And then a real question: You seem to send the setup
portion of the reply in every partial nttrans reply packet.
Is that the right way to do? I don't know how to trigger
that with Windows, but it looks wrong to me.

Not sure, draft-leach-cifs-v1-spec-02 is vaugue in this regard.
As you say, triggering a multi packet nttrans server response
will be difficult. I'm not sure what the maximum security descriptor
size is, but i'd assume I wont be able to hit it using
QUERY_SECURITY_DESC. I'll do some investigation.

Thanks!

Sorry if I'm picky on that, this is really tricky code that
we already had security bugs in in the past.

Volker

PGP SIGNATURE
Version: GnuPG v1.4.5 (GNU/Linux)


qZoqzxbocmEtkMLB+XMgJc=
=DjRd
PGP SIGNATURE

* Volker Lendecke wrote, 23/06/08 04:40:
Mon, Jun 23, 2008 at 11:21:44AM +1000, David Disseldorp wrote:

First a purely stylistic, trivial one: We're trying to
standardize on uint16_t, not uint16 these days. For new code
that should be the the one to use.

Then another stylistic one: The do {} while variant of a
loop is a bit cumbersome to read. Can we turn that into the
old form again?

>No problems, i'll change the areas above.
>>
>
And then a real question: You seem to send the setup
portion of the reply in every partial nttrans reply packet.
Is that the right way to do? I don't know how to trigger
that with Windows, but it looks wrong to me.

>Not sure, draft-leach-cifs-v1-spec-02 is vaugue in this regard.
>As you say, triggering a multi packet nttrans server response
>will be difficult. I'm not sure what the maximum security descriptor
>size is, but i'd assume I wont be able to hit it using
>QUERY_SECURITY_DESC. I'll do some investigation.
>
>
Thanks!
>
Sorry if I'm picky on that, this is really tricky code that
we already had security bugs in in the past.

I've been triggering multi-packet nttrans responses, is there some
testing I can do for you?

Sam