rsyncrypto-devel — Development discussions, bug reports, and announcements for rsyncrypto

Re: Version 1.11 released

[Julian <jul...@gm...>]

Hi Shachar.. hope I'm not disturbing your vacation... if so, you may ignore
this until you return, as it is not really urgent!

Anyway I noticed that on Windows:
if I copy the new rsyncrypto.exe file (V1.11) into a directory with all my
scripts etc..(without installing the msi) I get a "The system cannot execute
the specified program" error at the command line.

A quick google search shows that this is generally a DLL problem.. I noticed
the argtable2.dll is newer than previous versions (and smaller in size), but
copying this over does not fix the problem.

What does fix the problem is installing the msi into "Program
Files\Rsyncrypto"...
now the "other" exe now begins to work from the original place... Uninstall
the msi and the problem returns.

For information purposes, can you inform me of the exact dependencies of the
"rsyncrypto.exe" program to run?
Apologies if this has been implied from the previous posts about upgrading
to the new Visual Studio etc...

Thanks
Julian

2008/6/25 Julian <jul...@gm...>:

> Thanks Shachar.
>
> 2008/6/24 Shachar Shemesh <sh...@sh...>:
>
> Hi all,
>>
>> Version 1.11 of your favorite rsync friendly encryption program (it is,
>> isn't it?) has just been released. Many many many new stuff, addressing
>> almost all of the open issues recently raised.
>>
>> Compilation should now just work for cygwin, and as far as I can tell,
>> for Mac OS X (not sure about that, though). I can't tell if the run time
>> problem has been resolved or not, as it does not happen on my systems.
>>
>> Error messages have been greatly improved. If a file cannot be opened,
>> rsyncrypto will report which file that was. Also, in case of an error,
>> only the errored file will be aborted, and rsyncrypto will continue its
>> operation. It will print an additional error report at the end of the
>> entire encryption process.
>>
>> Also, I have finally fixed the oldest bug of them all. The one that
>> tripped Frederico. If an attempt is made to decrypt a file with no valid
>> symmetric key, it will be reported as an error and processing will
>> continue, rather than issue a segmentation fault.
>>
>> Please bear in mind that I am not 100% sure that my code for detecting
>> whether the private key is available is correct. Technical details
>> further on, but in for those not interested in the details, please check
>> this with your system, and make sure cold decryption works for you.
>>
>> As usual, share and enjoy.
>> Shachar
>>
>> Technical stuff:
>> RSA works by taking a modulo based power. So if the message is "m", the
>> encrypted message C will be M^e mod n. e is a fairly standard number
>> (typically, either 3 or 2^16+1 = 65537). "n" is the "public key", and is
>> devised by generating two prime numbers, called "p" and "q", where
>> n=p*q. "p" and "q" are the private key.
>>
>> What some people do not know is that you don't actually need p and q in
>> order to perform a decryption. p and q are not, theoretically, used
>> directly. Instead, a number, d, is derived from p and q. The decryption
>> process can be described as M = C^d mod n. This means you need d and n
>> in order to decrypt, but you don't need p and q.
>>
>> Typically, p and q are being stored, for no other reason than to save on
>> processing. In practice, openssl will typically calculate M1 = C^d mod p
>> and M2 = C^D mod q, and then combine M1 and M2 into M using the Chinese
>> remainder theorem. For that reason, an OpenSSL private key will,
>> typically, have p and q, and these are the numbers that I check exist or
>> not to find out whether I have the private key.
>>
>> Like I said before, the private key can be used even without p and q. If
>> that is the case, rsyncrypto may incorrectly deduce that the private key
>> is not present, and fail the decryption despite all data being
>> available. This is what I want you all to test for me - that you can
>> perform cold (i.e. - without the symmetric keys) decryption with your
>> private key.
>>
>> Thanks
>>
>>
>> -------------------------------------------------------------------------
>> Check out the new SourceForge.net Marketplace.
>> It's the best place to buy or sell services for
>> just about anything Open Source.
>> http://sourceforge.net/services/buy/index.php
>> _______________________________________________
>> Rsyncrypto-devel mailing list
>> Rsy...@li...
>> https://lists.sourceforge.net/lists/listinfo/rsyncrypto-devel
>>
>
>

Re: Version 1.11 released

[Julian <jul...@gm...>]

Thanks Shachar.

2008/6/24 Shachar Shemesh <sh...@sh...>:

> Hi all,
>
> Version 1.11 of your favorite rsync friendly encryption program (it is,
> isn't it?) has just been released. Many many many new stuff, addressing
> almost all of the open issues recently raised.
>
> Compilation should now just work for cygwin, and as far as I can tell,
> for Mac OS X (not sure about that, though). I can't tell if the run time
> problem has been resolved or not, as it does not happen on my systems.
>
> Error messages have been greatly improved. If a file cannot be opened,
> rsyncrypto will report which file that was. Also, in case of an error,
> only the errored file will be aborted, and rsyncrypto will continue its
> operation. It will print an additional error report at the end of the
> entire encryption process.
>
> Also, I have finally fixed the oldest bug of them all. The one that
> tripped Frederico. If an attempt is made to decrypt a file with no valid
> symmetric key, it will be reported as an error and processing will
> continue, rather than issue a segmentation fault.
>
> Please bear in mind that I am not 100% sure that my code for detecting
> whether the private key is available is correct. Technical details
> further on, but in for those not interested in the details, please check
> this with your system, and make sure cold decryption works for you.
>
> As usual, share and enjoy.
> Shachar
>
> Technical stuff:
> RSA works by taking a modulo based power. So if the message is "m", the
> encrypted message C will be M^e mod n. e is a fairly standard number
> (typically, either 3 or 2^16+1 = 65537). "n" is the "public key", and is
> devised by generating two prime numbers, called "p" and "q", where
> n=p*q. "p" and "q" are the private key.
>
> What some people do not know is that you don't actually need p and q in
> order to perform a decryption. p and q are not, theoretically, used
> directly. Instead, a number, d, is derived from p and q. The decryption
> process can be described as M = C^d mod n. This means you need d and n
> in order to decrypt, but you don't need p and q.
>
> Typically, p and q are being stored, for no other reason than to save on
> processing. In practice, openssl will typically calculate M1 = C^d mod p
> and M2 = C^D mod q, and then combine M1 and M2 into M using the Chinese
> remainder theorem. For that reason, an OpenSSL private key will,
> typically, have p and q, and these are the numbers that I check exist or
> not to find out whether I have the private key.
>
> Like I said before, the private key can be used even without p and q. If
> that is the case, rsyncrypto may incorrectly deduce that the private key
> is not present, and fail the decryption despite all data being
> available. This is what I want you all to test for me - that you can
> perform cold (i.e. - without the symmetric keys) decryption with your
> private key.
>
> Thanks
>
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> Rsyncrypto-devel mailing list
> Rsy...@li...
> https://lists.sourceforge.net/lists/listinfo/rsyncrypto-devel
>

Version 1.11 released

[Shachar S. <sh...@sh...>]

Hi all,

Version 1.11 of your favorite rsync friendly encryption program (it is, 
isn't it?) has just been released. Many many many new stuff, addressing 
almost all of the open issues recently raised.

Compilation should now just work for cygwin, and as far as I can tell, 
for Mac OS X (not sure about that, though). I can't tell if the run time 
problem has been resolved or not, as it does not happen on my systems.

Error messages have been greatly improved. If a file cannot be opened, 
rsyncrypto will report which file that was. Also, in case of an error, 
only the errored file will be aborted, and rsyncrypto will continue its 
operation. It will print an additional error report at the end of the 
entire encryption process.

Also, I have finally fixed the oldest bug of them all. The one that 
tripped Frederico. If an attempt is made to decrypt a file with no valid 
symmetric key, it will be reported as an error and processing will 
continue, rather than issue a segmentation fault.

Please bear in mind that I am not 100% sure that my code for detecting 
whether the private key is available is correct. Technical details 
further on, but in for those not interested in the details, please check 
this with your system, and make sure cold decryption works for you.

As usual, share and enjoy.
Shachar

Technical stuff:
RSA works by taking a modulo based power. So if the message is "m", the 
encrypted message C will be M^e mod n. e is a fairly standard number 
(typically, either 3 or 2^16+1 = 65537). "n" is the "public key", and is 
devised by generating two prime numbers, called "p" and "q", where 
n=p*q. "p" and "q" are the private key.

What some people do not know is that you don't actually need p and q in 
order to perform a decryption. p and q are not, theoretically, used 
directly. Instead, a number, d, is derived from p and q. The decryption 
process can be described as M = C^d mod n. This means you need d and n 
in order to decrypt, but you don't need p and q.

Typically, p and q are being stored, for no other reason than to save on 
processing. In practice, openssl will typically calculate M1 = C^d mod p 
and M2 = C^D mod q, and then combine M1 and M2 into M using the Chinese 
remainder theorem. For that reason, an OpenSSL private key will, 
typically, have p and q, and these are the numbers that I check exist or 
not to find out whether I have the private key.

Like I said before, the private key can be used even without p and q. If 
that is the case, rsyncrypto may incorrectly deduce that the private key 
is not present, and fail the decryption despite all data being 
available. This is what I want you all to test for me - that you can 
perform cold (i.e. - without the symmetric keys) decryption with your 
private key.

Thanks

Re: Rsyncrypto on Windows Vista

[Shachar S. <sh...@sh...>]

Thomas Constans wrote:
>
>
> 15d14
> < #define S_IFLNK 0120000
> 191,193c190
> <       if( data.dwFileAttributes&FILE_ATTRIBUTE_REPARSE_POINT ) {
> <          ret.st_mode=S_IFLNK;
> <       } else if( data.dwFileAttributes&FILE_ATTRIBUTE_DIRECTORY ) {
> ---
>   
>>         if( data.dwFileAttributes&FILE_ATTRIBUTE_DIRECTORY ) {
>>     
>
>
>   
Okay, thanks for the feedback.

I've committed the change (well, more or less). In the future, please 
keep the following points in mind when you send patches:
- The order in which you compare the files is important. Your patch is 
reversed, which means it will turn a patched version into an unpatched 
version.
- Use unified diff format. For "diff", this is done with -u.
- Use the correct file path. Patches should be made to be applied with 
either -p0 or -p1.
- The easiest way to generate the patch, AND make sure it complies with 
everything i just said, is to use subversion's "diff" command. It is 
also available on Windows through tortoise SVN. This way you know the 
patches you produce are ok.
- If possible, try to attach the patches instead of quoting them inline. 
Try to make sure, however, that your mail client puts them with a MIME 
type that makes the result quoted inline. Thunderbird does that 
automatically for .patch and .diff files.

Shachar

Re: compiling on Mac OSX 10.5.3

[Shachar S. <sh...@sh...>]

Philippe Niquille wrote:
> Compiling worked after adding some mmap includes (see patch)! But the 
> strange thing now is, that the actual build doesn't seem to work. It 
> outputs strange errors which I can't interpret. It still seems to have 
> problems with mmap?!
Hi Philippe,

I'm a bit at a loss for words. There is really not enough information in 
the report to go by, and I cannot think of a good way to get more 
information. Apparently, mmap is called with an argument the system 
doesn't like, but without access to the relevant documentation and 
platform, I fail to see how I can debug this.

Either run the system inside a debugger and at least get an accurate and 
*detailed* description of the problem, or another solution will need to 
be found.

Thanks,
Shachar

Re: compiling on Mac OSX 10.5.3

[Shachar S. <sh...@sh...>]

Philippe Niquille wrote:
> Hmm I applied your patch and I still get the following:
>
> make  all-am
> g++ -DHAVE_CONFIG_H -I.   -I../openssl-0.9.8h//include 
> -I../argtable2-9/src  -g -O2 -MT main.o -MD -MP -MF .deps/main.Tpo -c 
> -o main.o main.cpp
> autommap.h: In constructor 'autommap::autommap(void*, size_t, int, 
> int, int, off_t)':
> autommap.h:37: error: 'mmap' was not declared in this scope
> autommap.h: In constructor 'autommap::autommap(file_t, int)':
> autommap.h:53: error: 'MAP_SHARED' was not declared in this scope
> autommap.h: In member function 'void autommap::clear()':
> autommap.h:87: error: 'munmap' was not declared in this scope
> make[1]: *** [main.o] Error 1
> make: *** [all] Error 2
>
> I am on OS X 10.5.3, Intel.. Any idea?
Clearly, your development environment require a different include for 
"mmap" than mine. Either find out what that include is (man mmap may 
help you, recursive grep over the /usr/include folder if all else 
fails), or give me access to your environment. Feel free to upgrade my 
Mac to Leopard, pay pal donations welcome ;-)

Shachar

Re: segmentation fault at decryption

[Shachar S. <sh...@sh...>]

Frederico Rodrigues Abraham wrote:
> rsyncrypto -v -r -n /home/ugah/.ssh/filemap -d 
> /home/ugah/filesencrypted/files . /home/ugah/filesencrypted/keys 
> /home/ugah/.ssh/backup.crt
>
> I am getting the following output:
> -------------
> Decrypting /home/ugah/filesencrypted/files/A1D29FC1ED101FFC4DAD1CD3C92B9699
> Segmentation fault
> ---------
>
> What could be wrong?
>   
The only known cause of a segfault with rsyncrypto is documented in the 
man page:
> BUGS
>        Not providing a correct key file may result in segmentation fault.
In particular, if you try to perform a cold decryption (i.e. - without a 
stored symmetric key) using the public key file will, at present, 
produce a segmentation fault rather than an error message.

At least by going over the command line, it does not appear that this is 
what you tried to do. Please check the following:
Does /home/ugah/filesencrypted/keys/A1D29FC1ED101FFC4DAD1CD3C92B9699 
exist? If not, this is the cause of the problem.

If it doesn't exist, decrypting using backup.key (i.e. - the private key 
file) rather than backup.crt (the public key file) should solve your 
problem. If it does exist, please try the following in order and let us 
know what the results were:
1. Back up both keys/A1D29FC1ED101FFC4DAD1CD3C92B9699 and 
files/A1D29FC1ED101FFC4DAD1CD3C92B9699.
2. Try to decrypt it using the single file command line.
3. Run

tr -n '\0' '\n' < /home/ugah/.ssh/filemap | grep A1D29FC1ED101FFC4DAD1CD3C92B9699

Find out what the file's original name was. Assuming it was called 
"/home/ugah/files/foo" (should actually appear without the "home" part), 
try running:

rsyncrypto -v /home/ugah/files/foo /tmp/foo.enc /home/ugah/filesencrypted/keys/A1D29FC1ED101FFC4DAD1CD3C92B9699 /home/ugah/.ssh/backup.crt
rsyncrypto -v -d /tmp/foo.enc /tmp/foo.dec /home/ugah/filesencrypted/keys/A1D29FC1ED101FFC4DAD1CD3C92B9699 /home/ugah/.ssh/backup.crt
diff /home/ugah/files/foo /tmp/foo.dec
diff /home/ugah/filesencrypted/keys/A1D29FC1ED101FFC4DAD1CD3C92B9699 A1D29FC1ED101FFC4DAD1CD3C92B9699.backup

Tell us whether the whole cycle completed successfully, and whether the 
files compared were identical (A1D29FC1ED101FFC4DAD1CD3C92B9699.backup 
is, of course, the back up you made at step 1 above).

I am currently on vacation and not very available. I'll be back with 
normal Internet connection on Tuesday. Sorry if I'm not very responsive 
until then.

Shachar

Re: segmentation fault at decryption

[Frederico R. A. <dev...@gm...>]

  The file you asked exists.
  Strange is that I think I had already been able to decrypt a single 
file successfully. And I was using the public key.
  I tried now to decrypt recursively using the private key and it's working.
  Now that I think of it, it's pretty obvious. It shouldn't be possible 
to decrypt using the public key file, just using the private key.
  Thank you,
  -- Fred

Shachar Shemesh wrote:
> Frederico Rodrigues Abraham wrote:
>> rsyncrypto -v -r -n /home/ugah/.ssh/filemap -d 
>> /home/ugah/filesencrypted/files . /home/ugah/filesencrypted/keys 
>> /home/ugah/.ssh/backup.crt
>>
>> I am getting the following output:
>> -------------
>> Decrypting 
>> /home/ugah/filesencrypted/files/A1D29FC1ED101FFC4DAD1CD3C92B9699
>> Segmentation fault
>> ---------
>>
>> What could be wrong?
>>   
> The only known cause of a segfault with rsyncrypto is documented in 
> the man page:
>> BUGS
>>        Not providing a correct key file may result in segmentation 
>> fault.
> In particular, if you try to perform a cold decryption (i.e. - without 
> a stored symmetric key) using the public key file will, at present, 
> produce a segmentation fault rather than an error message.
>
> At least by going over the command line, it does not appear that this 
> is what you tried to do. Please check the following:
> Does /home/ugah/filesencrypted/keys/A1D29FC1ED101FFC4DAD1CD3C92B9699 
> exist? If not, this is the cause of the problem.
>
> If it doesn't exist, decrypting using backup.key (i.e. - the private 
> key file) rather than backup.crt (the public key file) should solve 
> your problem. If it does exist, please try the following in order and 
> let us know what the results were:
> 1. Back up both keys/A1D29FC1ED101FFC4DAD1CD3C92B9699 and 
> files/A1D29FC1ED101FFC4DAD1CD3C92B9699.
> 2. Try to decrypt it using the single file command line.
> 3. Run
>
> tr -n '\0' '\n' < /home/ugah/.ssh/filemap | grep 
> A1D29FC1ED101FFC4DAD1CD3C92B9699
>
> Find out what the file's original name was. Assuming it was called 
> "/home/ugah/files/foo" (should actually appear without the "home" 
> part), try running:
>
> rsyncrypto -v /home/ugah/files/foo /tmp/foo.enc 
> /home/ugah/filesencrypted/keys/A1D29FC1ED101FFC4DAD1CD3C92B9699 
> /home/ugah/.ssh/backup.crt
> rsyncrypto -v -d /tmp/foo.enc /tmp/foo.dec 
> /home/ugah/filesencrypted/keys/A1D29FC1ED101FFC4DAD1CD3C92B9699 
> /home/ugah/.ssh/backup.crt
> diff /home/ugah/files/foo /tmp/foo.dec
> diff /home/ugah/filesencrypted/keys/A1D29FC1ED101FFC4DAD1CD3C92B9699 
> A1D29FC1ED101FFC4DAD1CD3C92B9699.backup
>
> Tell us whether the whole cycle completed successfully, and whether 
> the files compared were identical 
> (A1D29FC1ED101FFC4DAD1CD3C92B9699.backup is, of course, the back up 
> you made at step 1 above).
>
> I am currently on vacation and not very available. I'll be back with 
> normal Internet connection on Tuesday. Sorry if I'm not very 
> responsive until then.
>
> Shachar
>
>

Re: compiling on Mac OSX 10.5.3

[Philippe N. <fl...@gm...>]

Hmm I applied your patch and I still get the following:

make  all-am
g++ -DHAVE_CONFIG_H -I.   -I../openssl-0.9.8h//include -I../argtable2-9/src
-g -O2 -MT main.o -MD -MP -MF .deps/main.Tpo -c -o main.o main.cpp
autommap.h: In constructor 'autommap::autommap(void*, size_t, int, int, int,
off_t)':
autommap.h:37: error: 'mmap' was not declared in this scope
autommap.h: In constructor 'autommap::autommap(file_t, int)':
autommap.h:53: error: 'MAP_SHARED' was not declared in this scope
autommap.h: In member function 'void autommap::clear()':
autommap.h:87: error: 'munmap' was not declared in this scope
make[1]: *** [main.o] Error 1
make: *** [all] Error 2

I am on OS X 10.5.3, Intel.. Any idea?

This is my gcc version, perhaps this helps:

Lena:rsyncrypto-1.10 fluppel$ gcc -v
Using built-in specs.
Target: i686-apple-darwin9
Configured with: /var/tmp/gcc/gcc-5465~16/src/configure --disable-checking
-enable-werror --prefix=/usr --mandir=/share/man
--enable-languages=c,objc,c++,obj-c++
--program-transform-name=/^[cg][^.-]*$/s/$/-4.0/
--with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/lib
--build=i686-apple-darwin9 --with-arch=apple --with-tune=generic
--host=i686-apple-darwin9 --target=i686-apple-darwin9
Thread model: posix
gcc version 4.0.1 (Apple Inc. build 5465)

Philippe

On Wed, Jun 18, 2008 at 10:39 AM, Shachar Shemesh <sh...@sh...>
wrote:

> Philippe Niquille wrote:
>
>> Hi
>>
> With the attached patch, the program compiles just fine on my system - Mac
> Mini PowePC with Mac OS X 10.4.11.
>
> It should be noted that while rsyncrypto compiles just fine, it cannot run
> properly because the system has no gzip with --rsyncable support. If you
> have a source for such a gzip for Mac, please let me know.
>
> Shachar
>

segmentation fault at decryption

[Frederico R. A. <dev...@gm...>]

Hi. I am trying to decrypt a previously encrypted directory and got a 
segmentation fault.

I encrypted the directory /home/ugah/files with the following command:

rsyncrypto --delete -c -n /home/ugah/.ssh/filemap -r /home/ugah/files 
/home/ugah/filesencrypted/files /home/ugah/filesencrypted/keys 
/home/ugah/.ssh/backup.crt

Now, at a different directory, I am trying to decrypt using the 
following command:

rsyncrypto -v -r -n /home/ugah/.ssh/filemap -d 
/home/ugah/filesencrypted/files . /home/ugah/filesencrypted/keys 
/home/ugah/.ssh/backup.crt

I am getting the following output:
-------------
Decrypting /home/ugah/filesencrypted/files/A1D29FC1ED101FFC4DAD1CD3C92B9699
Segmentation fault
---------

What could be wrong?
Should I generate rsyncrypto with debugging information? How to do that?
Thank you,
-- Fred

Re: Rsyncrypto on Windows Vista

[Thomas C. <tho...@op...>]

Le mercredi 18 juin 2008 à 12:23 +0200, Thomas Constans a écrit :
> Le mercredi 18 juin 2008 à 11:55 +0300, Shachar Shemesh a écrit :
> > Thomas Constans wrote:
> > > And rsyncrypto actually choke on such file, giving a "input/output
> > > error".
> > >   
> > I've uploaded a version with the patch to 
> > http://www.lingnu.com/downloads/Rsyncrypto-vistacheck.msi
> > 
> > Please let me know if it resolves the issue, so I can check it in.
> 
> Same issue :/
> 
> I'look into it as soon as i can get my VC express up and running
> 
> right now, it can't find libeay32.lib from openssl
> 
> Regards
> 

Hello,

The following patch is functional:

Yours would not work because a junction file pointing to a dir will pass
the 'FILE_ATTRIBUTE_DIRECTORY' successfully, and skip the
'FILE_ATTRIBUTE_REPARSE_POINT'.

I have just inverted the tests.

I have succesfully built and tried rsyncrypto with these modifications:

junction files are ignored with the message "skipping unhandled
filetype"

Regards


15d14
< #define S_IFLNK 0120000
191,193c190
<       if( data.dwFileAttributes&FILE_ATTRIBUTE_REPARSE_POINT ) {
<          ret.st_mode=S_IFLNK;
<       } else if( data.dwFileAttributes&FILE_ATTRIBUTE_DIRECTORY ) {
---
>         if( data.dwFileAttributes&FILE_ATTRIBUTE_DIRECTORY ) {




> 
-- 
Thomas Constans
openDoor
06 23 37 87 85
09 71 73 91 75

Re: Rsyncrypto on Windows Vista

[Thomas C. <tho...@op...>]

Le mercredi 18 juin 2008 à 11:55 +0300, Shachar Shemesh a écrit :
> Thomas Constans wrote:
> > And rsyncrypto actually choke on such file, giving a "input/output
> > error".
> >   
> I've uploaded a version with the patch to 
> http://www.lingnu.com/downloads/Rsyncrypto-vistacheck.msi
> 
> Please let me know if it resolves the issue, so I can check it in.

Same issue :/

I'look into it as soon as i can get my VC express up and running

right now, it can't find libeay32.lib from openssl

Regards


-- 
Thomas Constans
openDoor
06 23 37 87 85
09 71 73 91 75

Re: Rsyncrypto on Windows Vista

[Shachar S. <sh...@sh...>]

Thomas Constans wrote:
> And rsyncrypto actually choke on such file, giving a "input/output
> error".
>   
I've uploaded a version with the patch to 
http://www.lingnu.com/downloads/Rsyncrypto-vistacheck.msi

Please let me know if it resolves the issue, so I can check it in.

Thanks,
Shachar

Re: compiling on Mac OSX 10.5.3

[Shachar S. <sh...@sh...>]

Philippe Niquille wrote:
> Hi
With the attached patch, the program compiles just fine on my system - 
Mac Mini PowePC with Mac OS X 10.4.11.

It should be noted that while rsyncrypto compiles just fine, it cannot 
run properly because the system has no gzip with --rsyncable support. If 
you have a source for such a gzip for Mac, please let me know.

Shachar

Re: Rsyncrypto on Windows Vista

[David V. <dav...@gm...>]

Congratulations Shachar for your wedding !!!

David V.

On Tue, Jun 17, 2008 at 6:29 PM, Thomas Constans <
tho...@op...> wrote:

> Le mardi 17 juin 2008 à 20:01 +0300, Shachar Shemesh a écrit :
> > Thomas Constans wrote:
> > > I hope it will be ready soon. It is part of a global remote backup
> > > service i am setting up.
> > >
> > >
> > So you are competing with me.... :-)
>
> I think there is enough need out there for both of us :)
>
>
> > >
> > > unfortunately, i dont have a compilation plateform ready on my windows
> > > machine. Iam using the binary rsyncrypto version.
> > >
> > > you can either send me a binary patched version, or point me to some
> > > instructions to set up an appropriate build environnement.
> > >
> > >
> > I won't be able to send you a compiled version in the next week (getting
> > married + some vacation abroad. I doubt I'll even have Internet). There
> > are instructions in the rsyncrypto source code.
>
> Congratulations for the wedding !
>
> I am actually struggling to install visual studio express. I'll keep you
> informed of my progresses in this.
>
> Regards
>
>
> --
> Thomas Constans
> openDoor
> 06 23 37 87 85
> 09 71 73 91 75
>
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> Rsyncrypto-devel mailing list
> Rsy...@li...
> https://lists.sourceforge.net/lists/listinfo/rsyncrypto-devel
>

Re: Rsyncrypto on Windows Vista

[Thomas C. <tho...@op...>]

Le mardi 17 juin 2008 à 20:01 +0300, Shachar Shemesh a écrit :
> Thomas Constans wrote:
> > I hope it will be ready soon. It is part of a global remote backup
> > service i am setting up.
> >
> >   
> So you are competing with me.... :-)

I think there is enough need out there for both of us :)


> >
> > unfortunately, i dont have a compilation plateform ready on my windows
> > machine. Iam using the binary rsyncrypto version.
> >
> > you can either send me a binary patched version, or point me to some
> > instructions to set up an appropriate build environnement.
> >
> >   
> I won't be able to send you a compiled version in the next week (getting 
> married + some vacation abroad. I doubt I'll even have Internet). There 
> are instructions in the rsyncrypto source code.

Congratulations for the wedding !

I am actually struggling to install visual studio express. I'll keep you
informed of my progresses in this.

Regards


-- 
Thomas Constans
openDoor
06 23 37 87 85
09 71 73 91 75

Re: Rsyncrypto on Windows Vista

[Shachar S. <sh...@sh...>]

Thomas Constans wrote:
> I hope it will be ready soon. It is part of a global remote backup
> service i am setting up.
>
>   
So you are competing with me.... :-)
>
> unfortunately, i dont have a compilation plateform ready on my windows
> machine. Iam using the binary rsyncrypto version.
>
> you can either send me a binary patched version, or point me to some
> instructions to set up an appropriate build environnement.
>
>   
I won't be able to send you a compiled version in the next week (getting 
married + some vacation abroad. I doubt I'll even have Internet). There 
are instructions in the rsyncrypto source code.

It is preferable to get the latest version from SVN rather than 
downloading the source code. It's easier to keep thing up to date that way.

Shachar

Re: Rsyncrypto on Windows Vista

[Thomas C. <tho...@op...>]

Le mardi 17 juin 2008 à 18:36 +0300, Shachar Shemesh a écrit :
> Thomas Constans wrote:
> > Hello,
> >
> > First of all, many thanks for this nice piece of software !
> >
> > I am actually building a pygtk frontend to rsync + rsyncrypto.
> >   
> Cool. Send it here when it's ready :-)

I hope it will be ready soon. It is part of a global remote backup
service i am setting up.

you can get a "binary" test version here:
https://backup.opendoor.fr/uploads/Main/install.exe

I ll put the sources online as soon as i can.
> > I was having some troubles on the newest (and crappiest) microsoft
> > product:
> > To support old applications, windows xp style directories (my documents,
> > application data, and so forth) are implemented in Windows Vista using
> > some kind of symlink, called "junction".
> >
> > And rsyncrypto actually choke on such file, giving a "input/output
> > error".
> >   
> Sadly, I have to admit that I do not have Vista around, and I have been 
> trying very hard to avoid it up until now. It seems I'll have to go get 
> me a copy :-(

i am in the same case. i had to buy an upgrade just to be sure my
software works on this platform. As a linux user, it is a real PITA to
give money to MS.

> 
> Amazing. So Windows Vista has "junction points" 
> (http://msdn.microsoft.com/en-us/library/bb968829(VS.85).aspx), but also 
> has symbolic links 
> (http://msdn.microsoft.com/en-us/library/aa365680(VS.85).aspx). And 
> guess what - they are not the same! Blah....
> 
> On Windows, rsyncrypto uses the GetFileAttributesEx function to figure 
> out what the type of the file is. The docs seem to suggest that junction 
> points will have FILE_ATTRIBUTE_REPARSE_POINT set. I'll see what can be 
> done with the code to make it work. As I don't have access to a Vista 
> machine, if you could verify that point, it would be much appreciated. A 
> tiny program to print (even hexa-decimal) the attributes of a junction 
> point and send the result here would be enough.
> > It would be nice if rsyncrypto can handle (meaning ignore) this kind of
> > file more graciously.
> >
> >   
> Can you try compiling the attached patch letting me know how it fares?

unfortunately, i dont have a compilation plateform ready on my windows
machine. Iam using the binary rsyncrypto version.

you can either send me a binary patched version, or point me to some
instructions to set up an appropriate build environnement.



Regards



-- 
Thomas Constans
openDoor
06 23 37 87 85
09 71 73 91 75

Re: Rsyncrypto on Windows Vista

[Shachar S. <sh...@sh...>]

Thomas Constans wrote:
> Hello,
>
> First of all, many thanks for this nice piece of software !
>
> I am actually building a pygtk frontend to rsync + rsyncrypto.
>   
Cool. Send it here when it's ready :-)
> I was having some troubles on the newest (and crappiest) microsoft
> product:
> To support old applications, windows xp style directories (my documents,
> application data, and so forth) are implemented in Windows Vista using
> some kind of symlink, called "junction".
>
> And rsyncrypto actually choke on such file, giving a "input/output
> error".
>   
Sadly, I have to admit that I do not have Vista around, and I have been 
trying very hard to avoid it up until now. It seems I'll have to go get 
me a copy :-(

Amazing. So Windows Vista has "junction points" 
(http://msdn.microsoft.com/en-us/library/bb968829(VS.85).aspx), but also 
has symbolic links 
(http://msdn.microsoft.com/en-us/library/aa365680(VS.85).aspx). And 
guess what - they are not the same! Blah....

On Windows, rsyncrypto uses the GetFileAttributesEx function to figure 
out what the type of the file is. The docs seem to suggest that junction 
points will have FILE_ATTRIBUTE_REPARSE_POINT set. I'll see what can be 
done with the code to make it work. As I don't have access to a Vista 
machine, if you could verify that point, it would be much appreciated. A 
tiny program to print (even hexa-decimal) the attributes of a junction 
point and send the result here would be enough.
> It would be nice if rsyncrypto can handle (meaning ignore) this kind of
> file more graciously.
>
>   
Can you try compiling the attached patch letting me know how it fares?
> Best regards
>
> Keep up the good work
>   
Shachar

Rsyncrypto on Windows Vista

[Thomas C. <tho...@op...>]

Hello,

First of all, many thanks for this nice piece of software !

I am actually building a pygtk frontend to rsync + rsyncrypto.

I was having some troubles on the newest (and crappiest) microsoft
product:
To support old applications, windows xp style directories (my documents,
application data, and so forth) are implemented in Windows Vista using
some kind of symlink, called "junction".

And rsyncrypto actually choke on such file, giving a "input/output
error".

I am actually going around this problem by using the --filelist option.

The actual filelist is generated by the following python code:

      try:
         myfile = open( filelist, "w" )
      except Exception, detail:
         print 'IO error ', detail
         sys.exit(1)

      for root, dirs, files in os.walk( path ):
         for f in files:
            p = os.path.join( root, f)
            myfile.write( os.path.join(root, f )+"\n")
      myfile.close()
      return filelist

It would be nice if rsyncrypto can handle (meaning ignore) this kind of
file more graciously.

Best regards

Keep up the good work


-- 
Thomas Constans
openDoor
06 23 37 87 85
09 71 73 91 75

Re: compiling on Mac OSX 10.5.3

[Shachar S. <sh...@sh...>]

Philippe Niquille wrote:
> Hi
>
> I was wondering how I could compile rsyncrypto on mac systems. I tried 
> forcing a compile by deleting the # if define(__UNIX__) or altering it 
> to __APPLE__ but I result with this output:
>
I have a mac system, but I haven't got around to testing rsyncrypto 
thoroughly on it, especially on later builds. I will have a look at 
this, hopefully soon, and let you know.

As far as I can tell, this problem is a simple case of different 
includes necessary, and should be simple to solve once I find out how to 
set up a build environment on the mac.

Shachar

compiling on Mac OSX 10.5.3

[Philippe N. <fl...@gm...>]

Hi

I was wondering how I could compile rsyncrypto on mac systems. I tried
forcing a compile by deleting the # if define(__UNIX__) or altering it to
__APPLE__ but I result with this output:

Lena:rsyncrypto-1.10 fluppel$ make
make  all-am
g++ -DHAVE_CONFIG_H -I.   -I../openssl-0.9.8h//include -I../argtable2-9/src
 -g -O2 -MT main.o -MD -MP -MF .deps/main.Tpo -c -o main.o main.cpp
autommap.h: In constructor 'autommap::autommap(void*, size_t, int, int, int,
off_t)':
autommap.h:37: error: 'mmap' was not declared in this scope
autommap.h: In constructor 'autommap::autommap(file_t, int)':
autommap.h:53: error: 'MAP_SHARED' was not declared in this scope
autommap.h: In member function 'void autommap::clear()':
autommap.h:87: error: 'munmap' was not declared in this scope
main.cpp: At global scope:
main.cpp:200: fatal error: opening dependency file .deps/main.Tpo:
Permission denied
compilation terminated.
make[1]: *** [main.o] Error 1
make: *** [all] Error 2

I was wondering what I need to change since those guys appear to have tested
it on mac osx..http://www.tropheesdulibre.org/rsyncrypto,213.html?lang=en

Has there been any progress on this post?
http://sourceforge.net/mailarchive/message.php?msg_id=98BA8CEE-A718-44E2-B10B-83874A64369C%40gmail.com

Thanks for your help, Philippe

New project web page

[Shachar S. <sh...@sh...>]

At http://rsyncrypto.lingnu.com.

It's a wiki, so if there is anything you want to add, feel free. Of 
course, registering an account first would be advisable (but, until the 
spam brings us down, not mandatory).

Shachar

Re: abort on error bug

[David V. <dav...@gm...>]

Shachar,

As you might already know I'm also very interested in this feature.

David V.

On Fri, Jun 13, 2008 at 8:23 AM, Julian <jul...@gm...> wrote:

> Hi Shachar,
> I'm planning to use rsyncrypto in a new server. The problem with this is
> that some of the files in question are very often locked and typically have
> unusually long file names, which many times causes rsyncrypto to bail out.
> In this case it would be ideal to have rsyncrypto output an error, but
> continue processing the files just the same.
>
> I know you were planning to work on this, so just purely out of
> curiosity... when could we expect the next release of version 1 to be
> available more or less?
>
> Best regards
> Julian
>
>
>
> 2008/6/11 Shachar Shemesh <sh...@sh...>:
>
>> Robin Lee Powell wrote:
>> > I'm already a commited rsyncrypto user, but I'm curious as to how
>> > http://duplicity.nongnu.org/ compares; they claim similar abilities.
>> >
>> > -Robin
>> >
>> >
>> Their list of technologies make the rsyncable claim questionable in my
>> mind, but I have not put them to the test yet.
>>
>> It's fairly simple to test, really. Create a 100MB file from
>> /dev/urandom, sync it, add a couple of bytes (or 17 - a nice number of
>> making sure they are not doing block based encryption restarts)
>> somewhere around the beginning, and resync. If the resync takes as long
>> as the original (space or transit wise), then you know they do not live
>> up to their claims.
>>
>> Shachar
>>
>> -------------------------------------------------------------------------
>> Check out the new SourceForge.net Marketplace.
>> It's the best place to buy or sell services for
>> just about anything Open Source.
>> http://sourceforge.net/services/buy/index.php
>> _______________________________________________
>> Rsyncrypto-devel mailing list
>> Rsy...@li...
>> https://lists.sourceforge.net/lists/listinfo/rsyncrypto-devel
>>
>
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> Rsyncrypto-devel mailing list
> Rsy...@li...
> https://lists.sourceforge.net/lists/listinfo/rsyncrypto-devel
>
>

abort on error bug

[Julian <jul...@gm...>]

Hi Shachar,
I'm planning to use rsyncrypto in a new server. The problem with this is
that some of the files in question are very often locked and typically have
unusually long file names, which many times causes rsyncrypto to bail out.
In this case it would be ideal to have rsyncrypto output an error, but
continue processing the files just the same.

I know you were planning to work on this, so just purely out of curiosity...
when could we expect the next release of version 1 to be available more or
less?

Best regards
Julian



2008/6/11 Shachar Shemesh <sh...@sh...>:

> Robin Lee Powell wrote:
> > I'm already a commited rsyncrypto user, but I'm curious as to how
> > http://duplicity.nongnu.org/ compares; they claim similar abilities.
> >
> > -Robin
> >
> >
> Their list of technologies make the rsyncable claim questionable in my
> mind, but I have not put them to the test yet.
>
> It's fairly simple to test, really. Create a 100MB file from
> /dev/urandom, sync it, add a couple of bytes (or 17 - a nice number of
> making sure they are not doing block based encryption restarts)
> somewhere around the beginning, and resync. If the resync takes as long
> as the original (space or transit wise), then you know they do not live
> up to their claims.
>
> Shachar
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> Rsyncrypto-devel mailing list
> Rsy...@li...
> https://lists.sourceforge.net/lists/listinfo/rsyncrypto-devel
>