[ On Tuesday, January 28, 2003 at 08:38:31 (+0100), Fabian Cenedese wrote: ]
> Subject: Re: Discouraging :local:
>
>
> > > Well, generically speaking Ethernet's FCS field is a 32-bit CRC of the
> > > whole data frame. However if I understand the math correctly t
[ On Monday, January 27, 2003 at 22:38:40 (-0800), Kenneth Porter wrote: ]
> Subject: Re: Discouraging :local:
>
> One could presumably enhance this by encrypting the connection (eg. SSL) so
> that the encryption system supplies another layer of error detection.
> Anyone know h
Fabian Cenedese writes:
>
> As far as I followed the discussions here I think that the problem is not
> the main transport over ethernet but the real (not fully lockable) cvs
> operation on the server if you access a NFS repository with :local:
> Only if the server cvs does the operation itself it
> Well, generically speaking Ethernet's FCS field is a 32-bit CRC of the
> whole data frame. However if I understand the math correctly that means
> that only 32-bit or shorter errors (remember Ethernet is serial) can be
> detected reliabliy and "only" about 99.955% of error bursts longer than
>
--On Monday, January 27, 2003 6:20 PM -0500 "Greg A. Woods"
<[EMAIL PROTECTED]> wrote:
> As far as I know samba has no locking protocol (I
> don't think the underlying SMB protocol has locking either, but I may be
> mistaken).
There's something called an "opportunistic lock" or "oplock", opportun
[ On Monday, January 27, 2003 at 02:48:59 (-0800), Kenneth Porter wrote: ]
> Subject: Re: Discouraging :local:
>
> --On Saturday, January 25, 2003 2:42 PM -0500 "Greg A. Woods"
> <[EMAIL PROTECTED]> wrote:
>
> > The latter, the sharing part, is where
--On Saturday, January 25, 2003 2:42 PM -0500 "Greg A. Woods"
<[EMAIL PROTECTED]> wrote:
The latter, the sharing part, is where the real trouble begins.
Ensuring reliable order of operations for various operations which would
be "atomic" on a local filesystem is very very difficult (literally
imp
Kenneth Porter writes:
>
> But *why* is that bad? After all, a SCSI disk is on the other end of a SCSI
> cable, and so is "networked" in some sense. Why is that ok but a "network"
> disk is not?
Because the SCSI protocol, while horribly complicated in its own right,
is simple compared to network
[ On Friday, January 24, 2003 at 21:57:57 (-0800), Kenneth Porter wrote: ]
> Subject: Re: Discouraging :local:
>
> --On Thursday, January 23, 2003 12:43 PM -0500 Larry Jones
> <[EMAIL PROTECTED]> wrote:
>
> > What makes :local: inadvisable is the disk not being local, b
> --On Thursday, January 23, 2003 12:43 PM -0500 Larry Jones
> <[EMAIL PROTECTED]> wrote:
>
> > What makes :local: inadvisable is the disk not being local, but rather
> > being on some kind of network filesystem. I don't know of any way to
> > detect that.
>
> But *why* is that bad? After all, a
--On Thursday, January 23, 2003 12:43 PM -0500 Larry Jones
<[EMAIL PROTECTED]> wrote:
> What makes :local: inadvisable is the disk not being local, but rather
> being on some kind of network filesystem. I don't know of any way to
> detect that.
But *why* is that bad? After all, a SCSI disk is on
Kenneth Porter writes:
>
> Perhaps a better way to phrase the issue is: What properties of a
> filesystem make :local: inadvisable, and can those properties be easily
> detected?
What makes :local: inadvisable is the disk not being local, but rather
being on some kind of network filesystem. I do
--On Wednesday, January 22, 2003 12:08 PM -0500 Eric Siegerman
<[EMAIL PROTECTED]> wrote:
> That'd be nice. Rather a challenge to implement though -- how
> *does* one tell, portably and from application code, whether a
> given directory is locally or remotely mounted?
Perhaps a better way to phr
13 matches
Mail list logo
