|This is the talk page for discussing improvements to the Rsync article.|
|WikiProject Computing / Networking / Software||(Rated C-class, Mid-importance)|
- 1 How to read this word?
- 2 Question About Rsync.net
- 3 what are "remote" and "local" ?
- 4 Removed content copied from website
- 5 Tutorial link
- 6 On Portal:Free software, rsync is currently the selected article
- 7 rsync != librsync?
- 8 OS
- 9 psync?
- 10 "only one transmission"?
- 11 this entry is so confusingly written
- 12 MacOS compatibility?
- 13 Collision probability
- 14 linking to an example in the External Links
- 15 A practical explanation would be helpful!!
- 16 please fix circular link in the page
- 17 don't trim
How to read this word?
Question About Rsync.net
- Is the website related to rsync? It doesn't seem to be, apart from the name. So I would say "no". Thue | talk 18:15, 13 August 2007 (UTC)
what are "remote" and "local" ?
in the second paragraph, it is not clear what "remote" and "local" mean in daemon mode. It could go either way. if it was "client" and "server" the "server" would be the machine where the "daemon" is. 18.104.22.168 (talk) 18:53, 28 June 2011 (UTC)
Removed content copied from website
The command line options that were just reverted were copied directly from http://www.linuxdevcenter.com/linux/cmd/cmd.csp?path=r/rsync - should someone keep an eye on that IP address to check they don't do the same thing again? --Tango 18:42, 5 March 2006 (UTC)
The tutorial linked is "Last updated on November 20th, 1999", in other words ancient. There must exist a better one?
The External Link "Tutorial: Backing up files with rsync" http://www.linux.com/article.pl?sid=04/09/15/1931240 is redirected to a page with ad-only content. There is no tutorial there. Should it be removed?
On Portal:Free software, rsync is currently the selected article
(2007-04-18) Just to let you know. The purpose of selecting an article is both to point readers to the article and to highlight it to potential contributors. It will remain on the portal for a week or so. The previous selected article was WorldWideWeb. Gronky 11:32, 18 April 2007 (UTC)
- The selected article box has been updated again, rsync has been superceded by TeX. Gronky 14:19, 3 May 2007 (UTC)
rsync != librsync?
(2007-08-28) Looking at http://samba.anu.edu.au/rsync/ and http://librsync.sourceforge.net/ suggests that rsync and librsync contain two different implementations of a similar algorithm, with rdiff and rdiff-backup (mentioned in the article) using the latter. If this is the case then should the article should distinguish more between the algorithm, its various implementations and software that uses it. —Preceding unsigned comment added by Edmundgreen (talk • contribs) 14:48, August 28, 2007 (UTC)
- Unless there's another implementation of which I am unaware, rsync is UNIX only. In Windows, rsync leverages Cygwin, a POSIX (UNIX) compatibility layer (even the "standalone" rsync bundles). Whelkman (talk) 17:15, 5 September 2008 (UTC)
Never heard of it, and it's not even made a Debian package, so I guess it's not used much? One thing the rsync article doesn't make very clear is that it's used a lot. JöG (talk) 00:01, 9 January 2010 (UTC)
"only one transmission"?
This text in the intro: An important feature of rsync not found in most similar programs/protocols is that the mirroring takes place with only one transmission in each direction. — what is it trying to say? I'm very familiar with using rsync and know approximately how it works, but I have no idea what that text is trying to say. At least (a) define "transmission" and (b) explain why it's so important. JöG (talk) 00:10, 9 January 2010 (UTC)
this entry is so confusingly written
Collision probability of two hashes being the same is still 2-160. For example, if there was only 1 bit, the possibilities would be (0,0), (0,1), (1,0), (1,1), ergo 1/2 = 2-1 probability. You are correct in that because of the birthday paradox, you only need about 280 hashes before the collision is very probable. That still has no effect on the probability of a *single* collision. --Petteri Aimonen (talk) 16:25, 19 May 2012 (UTC)
I am attempting to link the following in the external links section:
Yes it is a blog, but it presents information that is relevant and currently important to most users of linux systems (system on which rsync runs). It shows how to use rsync in a manner that replicates Apple's Time Machine. This method isn't easy to find and is very helpful.22.214.171.124 (talk) 15:10, 7 September 2011 (UTC)
- Hi! I removed the link from the article because it goes against Wikipedia's guidelines for external links. Although the article might be useful, the external links section of Wikipedia is not the best place to promote it. Sorry about the trouble on this, and I hope you continue contributing to Wikipedia. --Odie5533 (talk) 15:14, 7 September 2011 (UTC)
- Hi :) Wouldn't the information available in that link fall under Number 4 of the ELNO? It contains information that is relevant and from a knowledgeable source though it may not be reliable. If it doesn't, what part of the ELNO does posting this link violate? I recently 'stumbled upon' the included link and it is very helpful for new users of linux for backing up their software using rsync. Since this article is about rsync and its backing up capabilities, I feel that this link warrents inclusion. 126.96.36.199 (talk) 16:01, 7 September 2011 (UTC)
A practical explanation would be helpful!!
Does Rsync go by file times to determine newness at all? And if so, how does it interpret them? People use Rsync even locally within filesystems and between external drives such as a USB dest. drive directly connected to the machine with the source drive from what I am able to gather. But if Rsync is doing all of this analyzing, and apparently not maintaining any databases (correct if wrong) would that not be more traffic between the drives than a straight copy? And if not... how can Rsync possibly guarantee the integrity of the files via a one time operation? It seems like if its going to be performing "rolling" checks over chunks of files then Rsync backup would require having Rsync rolling over the files so to speak nightly or as part of a sustained backup regime anyway... so to catch that one important change to a few bytes in some record in some binary file. Assuming the file system is not keeping track of that.
These questions seem to me what should be the meat of the article. I don't see any of these concerns being addressed. I don't have the answers, and can't seem to find the answers to easily myself. Thanks. Towards a more useful Wikipedia. --188.8.131.52 (talk) 11:17, 7 November 2011 (UTC)
- I was just wondering this myself, as an rsync of a few gigabytes of data only takes a few seconds if there are no differences. It couldn't possibly be doing a checksum on every file. The man page explains it properly. By default rsync checks the modification time and size of each file, and doesn't bother checking any files that have the same mod time and size. You can override this behaviour by using the --checksum option, which forces it to do a checksum on every file. The article probably needs updated to mention this. --sciencewatcher (talk) 04:04, 15 January 2013 (UTC)
The top of the page lists the information "(Redirected from Rdiff-backup)" while there is an rdiff-backup entry in the table at the bottom of the page.
Clicking "rdiff-backup" in the table simply returns the rsync page again. Stuff happens.
Oh. And rdiff-backup is not simply rsync. It's an application. Having its own page would be nice.