Gordon Ross wrote:
>> I'm using rdist to access files on a remote Windows system and
>> synchronize them with local files, essentially using rdist in
> [...]
>> Every time I run this command it finds something to update
> [...]
>> Is this a known problem with smbfs?
> 
> You're probably running into one of: file mode differences,
> owner/group differences, or possibly time differences.
> Unix and Windows have slightly different abilities to
> represent sub-second time, if I recall correctly.
> 
> The mode and owner differences are limitations of the
> current implementation, as described in: smbfs(7FS)

I can understand that some of these things would *always* be different,
but why would the differences change from run to run or rdist?

>> BTW, I was using smbfs on Ubuntu to do the same exact thing,
>> with no problems.
> 
> That's interesting.  The Linux smbfs is very similar to the
> OpenSolaris one w.r.t. user/group representation.  The modes
> on Linux will be the real thing with a server that supports
> the Unix extensions to SMB.  I'd be curious to know which
> file attribute causes rsync to decide an update is needed.

Me too.  How would I find out?

>> Is there a mount or config option that might be effecting this?
>>
>> Should I just file a bug?
> 
> There's an RFE for the Unix extensions, if that turns out to
> be what bothers rsync.  That CR is:  6647762

So these Unix extensions are something that Windows XP already
supports, but the client side support for them in smbfs is missing?
How ironic...

> Could you please run rsync with --verbose and try to find out
> exactly which file attribute is causing false compares?

I don't think the OpenSolaris version of rdist supports --verbose.
(The OpenSolaris version of rdist seems rather old, but that's a
separate discussion...)

There is a -D option, will that provide the needed information?
I'll try it...
_______________________________________________
cifs-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/cifs-discuss

Reply via email to