Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 12 Feb 2001 03:34:57 +0000 (GMT)
From:      Terry Lambert <tlambert@primenet.com>
To:        bp@butya.kz (Boris Popov)
Cc:        rwatson@FreeBSD.ORG (Robert Watson), freebsd-arch@FreeBSD.ORG
Subject:   Re: Darwin VFSisms - VOP_COPYFILE()
Message-ID:  <200102120334.UAA18209@usr08.primenet.com>
In-Reply-To: <Pine.BSF.4.21.0102120835250.55784-100000@lion.butya.kz> from "Boris Popov" at Feb 12, 2001 08:53:43 AM

next in thread | previous in thread | raw e-mail | index | archive | help
> 	Well, I think behavior of VOP_COPYFILE should very well
> documented, because any misbehavior may lead to significant data loss.
> 
> 	The major problem is that copyfile-like RPCs are very OS/protocol
> specific. For example, NCP allows user to copy any number of bytes from
> specified offset in the source file to specified offset in the destination
> file. SMB protocol doesn't support any of these parameters. But SMB
> protocol offers ability to copy multiple files (using wildcards) and even
> a MOVE RPC which deletes file(s) after copy.
> 
> 	I'm unsure, but some sort of 'capabilities' bits would be useful.

Better to just fail the call, if it used against an FS where it's
not implemented.  This is the way the other VOP's operate.

If you introduce capability bit, then you have to define them and
maintain them between operating systems.  One of the original goals
of the Heidemann stacking framework, and the reason that it uses
descriptors, it that they can be transparently passed through layers
or even proxied across a network, without intermediate layers (or
hosts) needing to be able to understand their contents.  Anything
that creates a need to rendesvous between a producer and consumer
unnecessarily is a bad thing.



					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200102120334.UAA18209>