Edward Ned Harvey wrote:
From: Afshin Salek [mailto:afshin.sa...@oracle.com]
Here are some pointers:
usr/src/uts/common/fs/smbsrv/smb_vss.c (smb kernel module)
usr/src/cmd/smbsrv/smbd/smbd_vss.c (smbd daemon)
Is it really difficult just to say "It's based on path and filename" or
"It's based on inodes" or "It's not based on either of those, it's more
complex, I'd recommend reading the code if you'd like to know more."
An unqualified answer might be misleading and trying to
provide a detailed answer without some common basis for
the discussion will probably be confusing.
For example, Previous Versions involves a reserved token
provided by the client, which determines where the previous
versions must be located. While this has relevance only
over SMB, it tends to drive towards a model based on file
system layout rather than znodes/inodes ... but awareness
of the mount hierarchy is required because you may need to
locate the correct .zfs within a hierarchy of file systems
(some of which may be zfs and some may be something else),
and how you determine that will probably depend on the
programming language or infrastructure you have chosen.
I mean, I feel like you're insulting me.
Not at all, this is why it's important to provide context
and perspective. You didn't mention your areas of
expertise and this is the typical answer one would get
to such a question within our organization.
I think it would be worth having a look at the Microsoft
specs, which are available here:
http://msdn.microsoft.com/en-us/library/cc964399%28PROT.10%29.aspx
Look for "[MS-SMB]: Server Message Block (SMB) Protocol
Specification" and search the PDF for "Previous Version".
There are lots references to that phrase in the document.
The name and location of the file is critical to Windows
Previous Versions. If you move or rename an object, it
may affect the results. Network captures, taken while
a Windows client is accessing Previous Versions, will
illustrate this very clearly.
A similar approach would work for your zhist command but
it depends on how you want to spec it. It might be possible
to use file nodes, although you'd have to take the mount
point (vfs id) into account and it might provide different,
and possibly undesirable, results.
Using your /tank/home/eharvey/working/foo/bar example, let's
assume that tank, home and eharvey are different datasets.
Would the following work:
zhist ls /tank/home/eharvey/working/foo/bar
Note that you can't get to bar in this example via
/tank/.zfs/snapshot/...
Suppose I have a symlink (fred is another dataset):
/tank/home/fred/bar -> ../eharvey/working/foo/bar
Since the target is in another dataset, should 'zhist ls
/tank/home/fred/bar' show me the previous versions of
/tank/home/eharvey/working/foo/bar?
Or worse, suppose bar is a hard link? Would this be possible
if the implementation was based on inodes/znodes?
How you model this will depend on the scope and requirements
you place on zhist.
Alan
_______________________________________________
cifs-discuss mailing list
cifs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/cifs-discuss
