On Sun, Jul 28, 2002 at 05:39:22PM +1000, Martin Pool wrote:
> On 27 Jul 2002, jw schultz <[EMAIL PROTECTED]> wrote:
> > The server has no need to deal with cleint limitations. I
> > am saying that the protocol would make the bare minimum of
> > limitatons (null termination, no nulls in names).
>
> It probably also makes sense to follow NFS4 in representing
> paths as a vector of components, rather than as a single string
> with '/'s in it or whatever. ['home', 'mbp', 'work', 'rsync'] avoids
> any worries about / vs \ vs :, and just lets the client do
> whatever makes sense.
That is _one_ of the reasons that i said filenames should be
CWD relative (no path components). That way the protocol
never needs to know about / vs \ with the possible exception
of links. The vector component list would address the isue
of link destinations nicely with a null terminated list of null
terminated strings 'home\0mbp\0work\0\rsync\0\0'.
> I don't know a lot about i18n support, but it does seem that
> programs will need to know what encoding to use for the filesystem
> on platforms that are not natively Unicode. On Unix it probably
> makes sense to default to UTF-8, but latin-1 or others are
> equally likely. This is independent of the choice of message
> locale. I think the W32 APIs are defined in Unicode so we don't
> need to worry.
>
> Quoting, translating, or rejecting illegal characters could all
> make sense depending on context.
I avoided the idea of rejection but there may be cases where
we need it. Rejection would mean the file would not be
transfered. For interactive use the default would be to
translate and would seldom be used because most transfers
would be of filesnames supported on both ends.
Any time a translation occurs a warning would be generated
unless silenced.
> I guess I see John's backup vs distribution question as
> hopefully being different profiles or wrappers around a single
> codebase, rather than different programs. Perhaps the distinction
> he's getting at is whether the "audience" for the client who
> uploaded the data is the same client, or somebody else?
The backup vs. distribution question seems to hang on what
we do when the storage semantics of the two nodes have a
mismatch. For backups we want to retain all data either
through lossless conversion or in some kind of meta-data
store. I'm inclined to take advantage of extended
attributes (NAME="rsync_perms" etc. ?) But for distribution
we can afford some meta-data loss as long as future
runs will compare correctly (ignore the loss).
I agree with you, this is either a different wrapper or
perhaps a mode setting multiple options. The biggest
difference seems to be on the server so perhaps the same
codebase might generate a server that has additional
capabilities but the client for both would be the same
regardless.
--
________________________________________________________________
J.W. Schultz Pegasystems Technologies
email address: [EMAIL PROTECTED]
Remember Cernan and Schmitt
--
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
