Skip to content
Projects
Groups
Snippets
Help
Loading...
Help
Submit feedback
Contribute to GitLab
Sign in
Toggle navigation
L
liblongpath-rsync
Project
Project
Details
Activity
Releases
Cycle Analytics
Repository
Repository
Files
Commits
Branches
Tags
Contributors
Graph
Compare
Charts
Issues
0
Issues
0
List
Board
Labels
Milestones
Merge Requests
0
Merge Requests
0
CI / CD
CI / CD
Pipelines
Jobs
Schedules
Charts
Wiki
Wiki
Members
Members
Collapse sidebar
Close sidebar
Activity
Graph
Charts
Create a new issue
Jobs
Commits
Issue Boards
Open sidebar
liblongpath
liblongpath-rsync
Commits
bde47ca7
Commit
bde47ca7
authored
May 13, 2002
by
Martin Pool
Browse files
Options
Browse Files
Download
Email Patches
Plain Diff
Note that using the old sockets API probably will not work
sufficiently on some ipv6 systems.
parent
ea7f8108
Changes
1
Show whitespace changes
Inline
Side-by-side
Showing
1 changed file
with
15 additions
and
8 deletions
+15
-8
TODO
TODO
+15
-8
No files found.
TODO
View file @
bde47ca7
...
...
@@ -313,14 +313,21 @@ Hard-link handling
IPv6
Put back the old socket code; if on a machine that does not properly
support the getaddrinfo API, then use it. This is probably much
simpler than reimplementing it. This might get us working again on
RedHat 5 and similar systems. Although the Kame patch seems like a
good idea, in fact it is a much broader interface than the
relatively narrow "open by name", "accept and log" interface that
rsync uses internally, and it has the disadvantage of clashing with
half-arsed implementations of the API.
Perhaps put back the old socket code; if on a machine that does not
properly support the getaddrinfo API, then use it. This is probably
much simpler than reimplementing it.
Alternatively, have two different files implementing the same
interface, and choose either the new or the old API. This is
probably necessary for systems that e.g. have IPv6, but
gethostbyaddr() can't handle it. The Linux manpage claims this is
currently the case.
This might get us working again on RedHat 5 and similar systems.
Although the Kame patch seems like a good idea, in fact it is a much
broader interface than the relatively narrow "open by name", "accept
and log" interface that rsync uses internally, and it has the
disadvantage of clashing with half-arsed implementations of the API.
Implement suggestions from http://www.kame.net/newsletter/19980604/
and ftp://ftp.iij.ad.jp/pub/RFC/rfc2553.txt
...
...
Write
Preview
Markdown
is supported
0%
Try again
or
attach a new file
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment