[Bug 9783] please don't use client-server model for local copies

2013-05-02 Thread samba-bugs 
https://bugzilla.samba.org/show_bug.cgi?id=9783

--- Comment #1 from Kilian CAVALOTTI  
2013-05-02 14:48:00 UTC ---
One way to easily reproduce this problem is to try to transfer a single large
file using rsync:

a. over ssh: 
  rsync -av host0:/path/to/file /tmp/file

b. locally, by mounting the remote path with sshfs: 
  sshfs host0:/path/to/ /path/to/
  rsync -av /path/to/file /tmp/file

Given any set of SSH options, b. gives about 60% of a.'s performance.

-- 
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the QA contact for the bug.
-- 
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

Re: Compilation error during rsync-3.0.9

2013-05-02 Thread Paul Slootman 
On Tue 30 Apr 2013, Gauri Senad wrote:
> 
> I am compiling rsync-3.0.9 in my build system (which is for 2.6.10 linux
> kernel. I am using windriver build system), compilation is failing due to
> size of “uint32” and “uint16” was computed wrongly during configuration.

Hmm, it took some googling to see that "windriver" should be parsed as
"wind-river" and not "win-driver" :-)

> checking size of int... (cached) 4
> checking size of long... (cached) 4
> checking size of long long... (cached) 8
> checking size of short... (cached) 2
> checking size of int16_t... 2
> *checking size of uint16_t... (cached) 0*
> checking size of int32_t... 4
> *checking size of uint32_t... (cached) 0*
> checking size of int64_t... 8
> checking size of off_t... (cached) 8
> checking size of off64_t... 8
> checking size of time_t... 4
> checking for inline... (cached) inline

> As I am new to this kind of build system I am confused, which file is
> referred for checking the values of variable
> “ac_cv_sizeof_uint32_t/checking size of uint16_t”
> ? As far as my study during this error debugging it seems the value is
> looked from the cache file.

There should be no cache file present the first time you run configure.
If there is, wipe the directory clean and unpack the rsync sources
again, and check that there is no cache file at that point.
Then rerun configure.


Paul
-- 
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

[Bug 8566] Spotlight comments (extended attributes) are not synced

2013-05-02 Thread samba-bugs 
https://bugzilla.samba.org/show_bug.cgi?id=8566

--- Comment #11 from Stefan Nowak  2013-05-02 10:27:05 UTC ---
Apple Developer Bug Reporting Team replied today:

Engineering has determined that this issue behaves as intended based on the
following information:
Comments are stored primarily in the .DS_Store files and mirrored to Spotlight
for searching. xattrs are not the primary storage.
This is the effect of attributes being stored externally, and command line
tools not being aware of them.

---

Now I realize why my rsync failed:
I had used --exclude=".*" which excluded .DS_Store from being synced!


Finder's metadata handling being only .DS_Store-aware and mostly ignoring
xattrs poses the following problems:

PROBLEM 1: It is neither fish nor fowl

a) The labels ARE considered from xattrs, more precisely at least ALSO
considered from xattrs.
Proof: rsync xattr sync results immediately visible in Finder.

b) Whereas the comments are considered SOLELY from .DS_store.
Proof: Rsync results not visible in Finder.
Workaround: See comment 10

PROBLEM 2: Partial file+metadata syncs are IMPOSSIBLE by design without
.DS_Store merging capabilities

Even if I would include .DS_Store files in my sync, synching a folder partially
MUST fail by design. Why?

If metadata would be per file, it is transported correctly on whatever
selection of files I sync over.
If metadata is per one .DS_Store per folder for multiple files, and you sync
only a few files plus the .DS_Store of that folder, you OVERWRITE the .DS_Store
on the destination.
Then the metadata for the files being both in the source and destination are
correct, but those only at the destination LOOSE their metadata. So a sync
process must be .DS_Store aware and MERGE .DS_Store from source and
destination, which practically EXCLUDES MOST 3rd PARTY apps from properly
syncing metadata!!!

What is my application: My entire projects are too large for my internal disk.
Therefore I eventually keep them on an external disk. The actual projects are
always on my internal disk, and I rsync them over additively (without the
option "delete on destination") to my external disk every here and then. If
eventually done, I sync a last time, and then erase on my internal disk.
Therefore my source (internal HD) is a subset of my external disk. And syncing
only parts over with a .DS_Store unaware tool would copy over only the synced
files' metadata but ERASE the metadata of all other files on the destination
(external HD).

EXAMPLE:
Source: 3, 4 -- all with metadata
Destination: 1, 2, 3, 7, 8 -- all with metadata
Outcome: If I sync over 3+4 with a DS_Store unaware sync tool, then 3 gets its
metadata updated, 4 gets copied freshly, and all others (1, 2, 7, 8) loose
their metadata!

-- 
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the QA contact for the bug.
-- 
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html