It was recently brought to my attention that a writable rsync daemon
that has "use chroot" enabled could potentially be tricked into loading
a user-supplied library file if the library can be uploaded into a spot
where a normal rsync action (such as an attempt to lookup a username
from an ID) would
On Fri, 2008-02-15 at 19:28 -0600, chuang liu wrote:
> I am trying to transfer a file from a machine A to a machine B. I ran
> a rsync deamon on machine B at a given port. Because there is a firewall
> between these two machines, I opened the port on the firewall. Is this
> enough to get rsync work
Wayne Davison wrote:
Your patch calls chflags(file,0) on every file/dir that is going to be
removed or renamed. Does that slow things down at all?
I didn't do any benchmark, but it doesn't appear that bad to me. It's
one extra syscall per unlink/rename, but I guess the time spent on i/o
is
On Fri, Feb 15, 2008 at 09:04:48PM +0100, Rolf Grossmann wrote:
> attached is the version of the flags patch, that is based on the one
> I'm using
Your patch calls chflags(file,0) on every file/dir that is going to be
removed or renamed. Does that slow things down at all?
My current flags patch
Hi all:
I am trying to transfer a file from a machine A to a machine B. I ran
a rsync deamon on machine B at a given port. Because there is a firewall
between these two machines, I opened the port on the firewall. Is this
enough to get rsync work through firewall?
When I tried the transfer, I got
https://bugzilla.samba.org/show_bug.cgi?id=5263
Summary: failure to report deleted files with link-dest
Product: rsync
Version: 3.0.0
Platform: All
OS/Version: All
Status: NEW
Severity: major
Priority: P3
C
I've corrected the bug that was making rsync crash, a silly pointer
issue (was using &value instead of value, shame on me).
I've also corrected a bracket bug in sys_llistxattr: sizeof foo is
dangerous as sizeof is a macro, works fine as value, but on return
variable it bugs. I've changed in size
Hi,
first of all, sorry for taking so long. Unfortunately, some other tasks
kept coming up. Anyway, attached is the version of the flags patch, that
is based on the one I'm using with 2.6.9. It is against the rsync-3.0.0pre9
release.
I've included the option name change from the repository, so th
On Fri, 2008-02-15 at 16:10 +0100, Vitorio Machado wrote:
> Better news! It compiles and it works!
> I'm joining the .diff to apply on a 3.0.0pre9 with flags and crtimes
> patches.
Congratulations on the progress!
> But as I said before, this is an alpha version, need testing before
> saying it
On Fri, 2008-02-15 at 11:09 +0100, Vitorio Machado wrote:
> 1) We need to put the "-framework Carbon" on the linking part of the
> makefile. I'm trying to put it in the darwin4-7 part of the
> configure.in (lines 937 and above) like this:
> darwin[[4-7]].*)
> AC_MSG_RESULT(Using OS X P
Better news! It compiles and it works!
I'm joining the .diff to apply on a 3.0.0pre9 with flags and crtimes
patches.
But as I said before, this is an alpha version, need testing before
saying it's functional. Be careful using it, it potentially still may
contains odd bugs!
I've successfully
Good news!!!
I got the problem!!!
i don't know why, the type FSIORefNum isn't defined like this. It
appears in the File System documentation, but in Files.h the FSOpenFork
is defined as using SInt16 instead of FSIORefNum. I've changed the type
and it goes further.
Made some more little change
12 matches
Mail list logo
