Thread: Please verify 1.01
Brought to you by:
thesun
From: Shachar S. <sh...@sh...> - 2007-01-17 19:39:05
|
Hi all, Please verify version 1.01 for your platform, and report here. As far as I know, 1.01 solved all problems introduced by 1.00, and also solved the >4GB files decryption bug on Windows. I would like to receive confirmation that you, indeed, manage to use the package. Thanks, Shachar |
From: Julian P. R. <jul...@gm...> - 2007-01-17 19:43:46
|
Hi Shachar, List Thanks. I will deploy it on my test platform, run all the test scripts and feedback the results hopefully tomorrow. Julian On 17/01/07, Shachar Shemesh <sh...@sh...> wrote: > > Hi all, > > Please verify version 1.01 for your platform, and report here. > > As far as I know, 1.01 solved all problems introduced by 1.00, and also > solved the >4GB files decryption bug on Windows. I would like to receive > confirmation that you, indeed, manage to use the package. > > Thanks, > > Shachar > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share > your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Rsyncrypto-devel mailing list > Rsy...@li... > https://lists.sourceforge.net/lists/listinfo/rsyncrypto-devel > |
From: Julian P. R. <jul...@gm...> - 2007-01-18 13:27:42
|
From preliminary tests I can verify the previously reported bug in 1.00 has vanished. Will continue more exhaustive tests in the coming weeks and report any unexpected behaviour. Thanks again Julian On 17/01/07, Julian Pace Ross <jul...@gm...> wrote: > > Hi Shachar, List > > Thanks. I will deploy it on my test platform, run all the test scripts and > feedback the results hopefully tomorrow. > > Julian > > > On 17/01/07, Shachar Shemesh <sh...@sh... > wrote: > > > > Hi all, > > > > Please verify version 1.01 for your platform, and report here. > > > > As far as I know, 1.01 solved all problems introduced by 1.00, and also > > solved the >4GB files decryption bug on Windows. I would like to receive > > confirmation that you, indeed, manage to use the package. > > > > Thanks, > > > > Shachar > > > > > > ------------------------------------------------------------------------- > > Take Surveys. Earn Cash. Influence the Future of IT > > Join SourceForge.net's Techsay panel and you'll get the chance to share > > your > > opinions on IT & business topics through brief surveys - and earn cash > > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > > > > _______________________________________________ > > Rsyncrypto-devel mailing list > > Rsy...@li... > > https://lists.sourceforge.net/lists/listinfo/rsyncrypto-devel > > > > |
From: Julian P. R. <jul...@gm...> - 2007-01-18 13:33:38
|
Is there a reason why there is openssl.exe in the windows distribution? On 17/01/07, Shachar Shemesh <sh...@sh...> wrote: > > Hi all, > > Please verify version 1.01 for your platform, and report here. > > As far as I know, 1.01 solved all problems introduced by 1.00, and also > solved the >4GB files decryption bug on Windows. I would like to receive > confirmation that you, indeed, manage to use the package. > > Thanks, > > Shachar > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share > your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Rsyncrypto-devel mailing list > Rsy...@li... > https://lists.sourceforge.net/lists/listinfo/rsyncrypto-devel > |
From: Shachar S. <sh...@sh...> - 2007-01-18 13:43:59
|
Julian Pace Ross wrote: > Is there a reason why there is openssl.exe in the windows distribution? Because it's useful for creating the keys, and I compiled it anyways? Shachar |
From: Julian P. R. <jul...@gm...> - 2007-01-18 14:01:25
|
OK just wanted to make sure there's no pipe to it, or something new like that. (havent browsed source since 0.19) Will keep posted. On 18/01/07, Shachar Shemesh <sh...@sh...> wrote: > > Julian Pace Ross wrote: > > Is there a reason why there is openssl.exe in the windows distribution? > Because it's useful for creating the keys, and I compiled it anyways? > > Shachar > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share > your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Rsyncrypto-devel mailing list > Rsy...@li... > https://lists.sourceforge.net/lists/listinfo/rsyncrypto-devel > |
From: Julian P. R. <jul...@gm...> - 2007-01-19 10:11:04
|
Hi Shachar I think something is affected in the stat functions... I noticed the following (as always under WinXP): When the destination directory and keys dir do not exist, rsyncrypto1.01exits with a "cannot stat" error. Just changing the executable to 0.19 and running the same command again, all works fine. On 18/01/07, Julian Pace Ross <jul...@gm...> wrote: > > OK just wanted to make sure there's no pipe to it, or something new like > that. (havent browsed source since 0.19) > Will keep posted. > > On 18/01/07, Shachar Shemesh <sh...@sh...> wrote: > > > > Julian Pace Ross wrote: > > > Is there a reason why there is openssl.exe in the windows > > distribution? > > Because it's useful for creating the keys, and I compiled it anyways? > > > > Shachar > > > > > > ------------------------------------------------------------------------- > > Take Surveys. Earn Cash. Influence the Future of IT > > Join SourceForge.net's Techsay panel and you'll get the chance to share > > your > > opinions on IT & business topics through brief surveys - and earn cash > > > > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > > _______________________________________________ > > Rsyncrypto-devel mailing list > > Rsy...@li... > > https://lists.sourceforge.net/lists/listinfo/rsyncrypto-devel > > > > |
From: Shachar S. <sh...@sh...> - 2007-01-20 10:39:31
|
Julian Pace Ross wrote: > Hi Shachar > Hi Julian, First, if you have a batched set of tests, I would love it if you could send it so that it will be included in the official package. > I think something is affected in the stat functions... Would a total rewrite be considered such a something? > I noticed the following (as always under WinXP): > When the destination directory and keys dir do not exist, > rsyncrypto1.01 exits with a "cannot stat" error. > Just changing the executable to 0.19 and running the same command > again, all works fine. I cannot seem to reconstruct the problem (Windows 2000). Can you give me the precise command line you tried, and what directories exist and what don't? Also, make sure you have tried it with 1.01, and not with 1.00. Thanks, Shachar |
From: Julian P. R. <jul...@gm...> - 2007-01-24 14:03:20
|
Hi Shachar sorry for the delay, I was away. >> First, if you have a batched set of tests, I would love it if you could >> send it so that it will be included in the official package. Not really.. just a set of scribbled notes to help me remember. Have been wanting to organise them into a test script for some time, and will definitely share it once its done. Regarding the cannot stat error, I tried a simple test on XP. I renamed the executables rsyncrypto101 and rsyncrypto019 in the same directory. This is what happens: (note that testdir2 and testdir3 do not yet exist before I start). C:\rsyncryptotest>rsyncrypto101.exe -rcv --delete \testdir \testdir2 \testdir3 backup.crt stat failed: No such file or directory Trying exactly the same thing with 0.19: C:\rsyncryptotest>rsyncrypto019.exe -rcv --delete \testdir \testdir2 \testdir3 backup.crt Encrypting \testdir\November0 2004.rar Encrypting \testdir\November1 2004.rar Encrypting \testdir\November2 2004.rar Encrypting \testdir\November3 2004.rar Encrypting \testdir\November4 2004.rar .... and so on Trying this immediately after (with all 3 dirs now existing) with 1.01 still gives the same error. I tried with without --delete and the other args with the same results. If you need me to try anything else just let me know. Regards Julian |
From: Shachar S. <sh...@sh...> - 2007-01-25 14:55:30
|
Julian Pace Ross wrote: > Hi Shachar > sorry for the delay, I was away. Sorry, that's not acceptable. I want my money back :-) > Regarding the cannot stat error, I tried a simple test on XP. I > renamed the executables rsyncrypto101 and rsyncrypto019 in the same > directory. This is what happens: (note that testdir2 and testdir3 do > not yet exist before I start). > > C:\rsyncryptotest>rsyncrypto101.exe -rcv --delete \testdir \testdir2 > \testdir3 backup.crt > stat failed: No such file or directory &%!&@^$%&!@#^$^!@&#^%&!@*$&%!#^%# Window's "FindFirstFile" cannot handle the root of a drive!!!!! Aaaarrrrgggghhhh!!!! Okay, okay, calm down. Time to look for ANOTHER way to determine what the relevant data about a file are, in a way that will work on root directories as well. Grrrr. I really hate Windows. Shachar |
From: Julian P. R. <jul...@gm...> - 2007-01-25 17:10:08
|
> I really hate Windows. Yep.. I wonder how people pay for it. Quite a posix fan myself... unfortunately the application i have for rsyncrypto is on Win clients... oh well BTW 1.01, as you probably know, works perfectly once the src/dest/keys dirs are given as relative to the current dir. Let me know if there are any fixes Cheers Julian Shachar > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share > your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Rsyncrypto-devel mailing list > Rsy...@li... > https://lists.sourceforge.net/lists/listinfo/rsyncrypto-devel > |
From: Shachar S. <sh...@sh...> - 2007-01-25 17:09:32
Attachments:
1.02testing.patch
rsyncrypto-1.02testing.zia
|
Julian Pace Ross wrote: > > If you need me to try anything else just let me know. > yes. I would love it if you could test rsyncrypto 1.02testing (attached compiled and as a patch against 1.01) and see whether it works for you. It seems that this "stat" rewrite is not going at all smoothly. Shachar P.s. it seems that sourceforge blocks all emails that have an attachement with the "zip" extension. Rather than ask them to change it, I have cunningly changed the extension of the relevant files. I will leave it up to you to solve the riddle of which of the attached files was renamed, and what to. |
From: Julian P. R. <jul...@gm...> - 2007-01-25 17:19:56
|
This now works: C:\rsyncryptotest> rsyncrypto102.exe -rcv "c:\testdir" "c:\testdir2" "c:\testdir3" backup.crt as does this: C:\rsyncryptotest> rsyncrypto102.exe -rcv ../testdir ../testdir2 ../testdir3 backup.crt but this doesn't: C:\rsyncryptotest> rsyncrypto102.exe -rcv \testdir \testdir2 \testdir3 backup.crt However, with the first and second cases, there's now again that problem with re-encrypting the whole thing again if the command is given again straight after (I believe this was what happened with 1.00) On 25/01/07, Shachar Shemesh <sh...@sh...> wrote: > > Julian Pace Ross wrote: > > > > If you need me to try anything else just let me know. > > > yes. I would love it if you could test rsyncrypto 1.02testing (attached > compiled and as a patch against 1.01) and see whether it works for you. > It seems that this "stat" rewrite is not going at all smoothly. > > Shachar > > P.s. > it seems that sourceforge blocks all emails that have an attachement > with the "zip" extension. Rather than ask them to change it, I have > cunningly changed the extension of the relevant files. I will leave it > up to you to solve the riddle of which of the attached files was > renamed, and what to. > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share > your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > > _______________________________________________ > Rsyncrypto-devel mailing list > Rsy...@li... > https://lists.sourceforge.net/lists/listinfo/rsyncrypto-devel > > > > |
From: Shachar S. <sh...@sh...> - 2007-01-25 17:40:19
|
Julian Pace Ross wrote: > This now works: > > C:\rsyncryptotest> rsyncrypto102.exe -rcv "c:\testdir" "c:\testdir2" > "c:\testdir3" backup.crt > > as does this: > > C:\rsyncryptotest> rsyncrypto102.exe -rcv ../testdir ../testdir2 > ../testdir3 backup.crt > > but this doesn't: > > C:\rsyncryptotest> rsyncrypto102.exe -rcv \testdir \testdir2 \testdir3 > backup.crt > > However, with the first and second cases, there's now again that > problem with re-encrypting the whole thing again if the command is > given again straight after (I believe this was what happened with 1.00) I'm not seeing that problem any more. All three forms of invocation work for me, and honor the -c flag. Can you, please, double check that you are using the version in the ".zia" file? Shachar |
From: Julian P. R. <jul...@gm...> - 2007-01-25 17:46:14
|
---------- Forwarded message ---------- From: Julian Pace Ross <jul...@gm...> Date: 25-Jan-2007 18:45 Subject: Re: Please verify 1.01 To: Shachar Shemesh <sh...@sh...> yep renamed as zip and extracted...in fact i can see "rsyncrypto1.02testing" when called without args, and moreover the first case listed didn't work with 1.01. I am using XP Pro SP2 I can imagine that this is quite frustrating for you. If there is anything you need me to try, just shove it over, be happy to. On 25/01/07, Shachar Shemesh <sh...@sh...> wrote: > > Julian Pace Ross wrote: > > This now works: > > > > C:\rsyncryptotest> rsyncrypto102.exe -rcv "c:\testdir" "c:\testdir2" > > "c:\testdir3" backup.crt > > > > as does this: > > > > C:\rsyncryptotest> rsyncrypto102.exe -rcv ../testdir ../testdir2 > > ../testdir3 backup.crt > > > > but this doesn't: > > > > C:\rsyncryptotest> rsyncrypto102.exe -rcv \testdir \testdir2 \testdir3 > > backup.crt > > > > However, with the first and second cases, there's now again that > > problem with re-encrypting the whole thing again if the command is > > given again straight after (I believe this was what happened with 1.00) > I'm not seeing that problem any more. All three forms of invocation work > for me, and honor the -c flag. Can you, please, double check that you > are using the version in the ".zia" file? > > Shachar > |
From: Shachar S. <sh...@sh...> - 2007-01-25 18:05:43
|
Julian Pace Ross wrote: > yep renamed as zip and extracted...in fact i can see > "rsyncrypto1.02testing" when called without args, and moreover the > first case listed didn't work with 1.01. > > I am using XP Pro SP2 Is this, by any chance, on a FAT partition? Can you paste here actual run outputs using double v? I.e. run the option that doesn't work (with \something) with -v -v and paste the output here. Shachar |
From: Julian P. R. <jul...@gm...> - 2007-01-25 18:24:10
|
My mistake: \Something DOES work.. made a typo in the args. (Didn't show up on the mail since I repasted and touched up the previous line). Sorry!!! However, still seeing the bug that does not skip all files in a consecutive run: TEST 1: ******************************************************************** Encrypting from scratch with 0.19, followed by a second run with 1.02: (These are random files copied onto this directory from various places on my hdd) C:\rsyncryptotest>rsyncrypto019.exe -rcvv \testdir \testdir2 \testdir3 backup.crt Encrypting \testdir\Copy (2) of Dhyana November 2004.rar Encrypting \testdir\Copy (3) of Copy of Dhyana November 2004.rar Encrypting \testdir\Copy (3) of Dhyana November 2004.rar Encrypting \testdir\Copy (4) of Copy of Dhyana November 2004.rar Encrypting \testdir\Copy (5) of Copy of Dhyana November 2004.rar Encrypting \testdir\Copy (5) of Dhyana November 2004.rar Encrypting \testdir\Copy (6) of Dhyana November 2004.rar Encrypting \testdir\Copy (7) of Copy of Dhyana November 2004.rar Encrypting \testdir\freeware hex editor\DOSWIN.XCT Encrypting \testdir\freeware hex editor\EBCDEWIN.XCT Encrypting \testdir\freeware hex editor\EBCUSWIN.XCT Encrypting \testdir\freeware hex editor\readme.txt Encrypting \testdir\freeware hex editor\WINDOS.XCT Encrypting \testdir\freeware hex editor\WINEBCDE.XCT Encrypting \testdir\freeware hex editor\WINEBCUS.XCT Encrypting \testdir\freeware hex editor\XVI32.exe Encrypting \testdir\freeware hex editor\XVI32.ini Encrypting \testdir\freeware hex editor\XVI32U.cnt Encrypting \testdir\freeware hex editor\XVI32U.HLP Encrypting \testdir\hex workshop\Hex Edit Key.txt Encrypting \testdir\hex workshop\hw32v422.exe Encrypting \testdir\hex workshop\hw32v423.exe C:\rsyncryptotest>rsyncrypto102.exe -rcvv \testdir \testdir2 \testdir3 backup.crt Skipping unchanged file \testdir\Copy (2) of Dhyana November 2004.rar Skipping unchanged file \testdir\Copy (3) of Copy of Dhyana November 2004.rar Skipping unchanged file \testdir\Copy (3) of Dhyana November 2004.rar Skipping unchanged file \testdir\Copy (4) of Copy of Dhyana November 2004.rar Skipping unchanged file \testdir\Copy (5) of Copy of Dhyana November 2004.rar Skipping unchanged file \testdir\Copy (5) of Dhyana November 2004.rar Skipping unchanged file \testdir\Copy (6) of Dhyana November 2004.rar Skipping unchanged file \testdir\Copy (7) of Copy of Dhyana November 2004.rar Skipping unchanged file \testdir\freeware hex editor\DOSWIN.XCT Skipping unchanged file \testdir\freeware hex editor\EBCDEWIN.XCT Skipping unchanged file \testdir\freeware hex editor\EBCUSWIN.XCT Skipping unchanged file \testdir\freeware hex editor\readme.txt Skipping unchanged file \testdir\freeware hex editor\WINDOS.XCT Skipping unchanged file \testdir\freeware hex editor\WINEBCDE.XCT Skipping unchanged file \testdir\freeware hex editor\WINEBCUS.XCT Skipping unchanged file \testdir\freeware hex editor\XVI32.exe Skipping unchanged file \testdir\freeware hex editor\XVI32.ini Skipping unchanged file \testdir\freeware hex editor\XVI32U.cnt Skipping unchanged file \testdir\freeware hex editor\XVI32U.HLP Skipping unchanged file \testdir\hex workshop\Hex Edit Key.txt Skipping unchanged file \testdir\hex workshop\hw32v422.exe Skipping unchanged file \testdir\hex workshop\hw32v423.exe TEST 2: ******************************************************************** Deleted testdir2 and 3 and retried: So, now encrypting from scratch with 1.02, followed by a second run with 1.02: C:\rsyncryptotest>rsyncrypto102.exe -rcvv \testdir \testdir2 \testdir3 backup.crt Encrypting \testdir\Copy (2) of Dhyana November 2004.rar Encrypting \testdir\Copy (3) of Copy of Dhyana November 2004.rar Encrypting \testdir\Copy (3) of Dhyana November 2004.rar Encrypting \testdir\Copy (4) of Copy of Dhyana November 2004.rar Encrypting \testdir\Copy (5) of Copy of Dhyana November 2004.rar Encrypting \testdir\Copy (5) of Dhyana November 2004.rar Encrypting \testdir\Copy (6) of Dhyana November 2004.rar Encrypting \testdir\Copy (7) of Copy of Dhyana November 2004.rar Encrypting \testdir\freeware hex editor\DOSWIN.XCT Encrypting \testdir\freeware hex editor\EBCDEWIN.XCT Encrypting \testdir\freeware hex editor\EBCUSWIN.XCT Encrypting \testdir\freeware hex editor\readme.txt Encrypting \testdir\freeware hex editor\WINDOS.XCT Encrypting \testdir\freeware hex editor\WINEBCDE.XCT Encrypting \testdir\freeware hex editor\WINEBCUS.XCT Encrypting \testdir\freeware hex editor\XVI32.exe Encrypting \testdir\freeware hex editor\XVI32.ini Encrypting \testdir\freeware hex editor\XVI32U.cnt Encrypting \testdir\freeware hex editor\XVI32U.HLP Encrypting \testdir\hex workshop\Hex Edit Key.txt Encrypting \testdir\hex workshop\hw32v422.exe Encrypting \testdir\hex workshop\hw32v423.exe C:\rsyncryptotest>rsyncrypto102.exe -rcvv \testdir \testdir2 \testdir3 backup.crt Skipping unchanged file \testdir\Copy (2) of Dhyana November 2004.rar Skipping unchanged file \testdir\Copy (3) of Copy of Dhyana November 2004.rar Skipping unchanged file \testdir\Copy (3) of Dhyana November 2004.rar Skipping unchanged file \testdir\Copy (4) of Copy of Dhyana November 2004.rar Skipping unchanged file \testdir\Copy (5) of Copy of Dhyana November 2004.rar Skipping unchanged file \testdir\Copy (5) of Dhyana November 2004.rar Skipping unchanged file \testdir\Copy (6) of Dhyana November 2004.rar Skipping unchanged file \testdir\Copy (7) of Copy of Dhyana November 2004.rar Encrypting \testdir\freeware hex editor\DOSWIN.XCT Encrypting \testdir\freeware hex editor\EBCDEWIN.XCT Encrypting \testdir\freeware hex editor\EBCUSWIN.XCT Encrypting \testdir\freeware hex editor\readme.txt Encrypting \testdir\freeware hex editor\WINDOS.XCT Encrypting \testdir\freeware hex editor\WINEBCDE.XCT Encrypting \testdir\freeware hex editor\WINEBCUS.XCT Encrypting \testdir\freeware hex editor\XVI32.exe Encrypting \testdir\freeware hex editor\XVI32.ini Encrypting \testdir\freeware hex editor\XVI32U.cnt Encrypting \testdir\freeware hex editor\XVI32U.HLP Skipping unchanged file \testdir\hex workshop\Hex Edit Key.txt Skipping unchanged file \testdir\hex workshop\hw32v422.exe Encrypting \testdir\hex workshop\hw32v423.exe If following this I now encrypt with 1.02 or 0.19, I get exactly the same output (some encrypted, some skipped.. the same files), the difference being that after any 0.19 run, both start properly skipping all files as in Test 1. This is repeatable. I cant possibly see what the difference between the skipped ones and the non skipped ones is. Hope this helps. Let me know. |
From: Shachar S. <sh...@sh...> - 2007-01-25 18:30:02
|
Julian Pace Ross wrote: > My mistake: \Something DOES work.. made a typo in the args. (Didn't > show up on the mail since I repasted and touched up the previous > line). Sorry!!! No problem. > I cant possibly see what the difference between the skipped ones and > the non skipped ones is. > Hope this helps. > Let me know. Ok, same question about filesystem. Is it FAT or NTFS? Shachar |
From: Julian P. R. <jul...@gm...> - 2007-01-25 18:33:45
|
Sorry forgot... definitely NTFS. On 25/01/07, Shachar Shemesh <sh...@sh...> wrote: > > Julian Pace Ross wrote: > > My mistake: \Something DOES work.. made a typo in the args. (Didn't > > show up on the mail since I repasted and touched up the previous > > line). Sorry!!! > No problem. > > I cant possibly see what the difference between the skipped ones and > > the non skipped ones is. > > Hope this helps. > > Let me know. > Ok, same question about filesystem. Is it FAT or NTFS? > > Shachar > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share > your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Rsyncrypto-devel mailing list > Rsy...@li... > https://lists.sourceforge.net/lists/listinfo/rsyncrypto-devel > |
From: Shachar S. <sh...@sh...> - 2007-01-25 18:58:00
|
Julian Pace Ross wrote: > Sorry forgot... definitely NTFS. Ok. Any tool for Windows that shows the file timestamp with seconds resolution? If so, can you give the files timestamps for the source, after encrypting with 0.19 and after encrypting with 1.02? If no such tool is readily available then just give me the output of "dir" for the encryption directory after encrypting with 1.02 and 0.19. Thanks, Shachar |
From: Julian P. R. <jul...@gm...> - 2007-01-25 19:49:52
|
Searched high and low for said tool to no avail. Also cant get CLI to display seconds. So I am taking one file as an example and using the GUI's Properties in the context menu to display file properties: The file in question is: \testdir\freeware hex editor\readme.txt This is one of those that 1.02 keeps re-encrypting. SOURCE DIR: (this remains unchanged after using both 0.19 and 1.02) Created: 24 January 2007, 14:49:28 Modified: 25 July 2005, 14:52:08 Accessed: 25 January 2007, 20:37:55 DESTDIR: (encrypted file) after 0.19 run: Created: 25 January 2007, 20:40:40 Modified: 25 July 2005, 14:52:08 Accessed: 25 January 2007, 20:37:55 DESTDIR: (encrypted file) after 1.02 run: Created: 25 January 2007, 20:42:30 Modified: 25 July 2005, 15:52:08 Accessed: 25 January 2007, 20:42:30 <<< Note change in accessed time (?) Hope there lies a clue for you within... I'm calling it quits for today (its nearly 9pm here), but please keep sending mail with anything you'd like me to try and i'll continue in the morning. Cheers Julian On 25/01/07, Shachar Shemesh <sh...@sh...> wrote: > > Julian Pace Ross wrote: > > Sorry forgot... definitely NTFS. > Ok. Any tool for Windows that shows the file timestamp with seconds > resolution? If so, can you give the files timestamps for the source, > after encrypting with 0.19 and after encrypting with 1.02? > > If no such tool is readily available then just give me the output of > "dir" for the encryption directory after encrypting with 1.02 and 0.19. > > Thanks, > Shachar > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share > your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Rsyncrypto-devel mailing list > Rsy...@li... > https://lists.sourceforge.net/lists/listinfo/rsyncrypto-devel > |
From: Shachar S. <sh...@sh...> - 2007-01-25 20:57:56
|
Julian Pace Ross wrote: > Accessed: 25 January 2007, 20:42:30 <<< Note change in accessed time > (?) No, rsyncrypto checks the modified time, not the accessed time. I see another difference, however: > > SOURCE DIR: (this remains unchanged after using both 0.19 and 1.02) > Modified: 25 July 2005, 14:52:08 > DESTDIR: (encrypted file) after 0.19 run: > Modified: 25 July 2005, 14:52:08 > DESTDIR: (encrypted file) after 1.02 run: > Modified: 25 July 2005, 15:52:08 > May I suggest that the files that get synced incorrectly are those in daylight saving time? Can you check whether there is a good match? In the mean while, I'll try to figure out what went wrong with the conversion. Shachar |
From: Shachar S. <sh...@sh...> - 2007-01-25 22:20:06
Attachments:
rsyncrypto-1.02testing2.zia
1.02testing2.patch
|
Julian Pace Ross wrote: > > Modified: 25 July 2005, 14:52:08 > Modified: 25 July 2005, 14:52:08 > Modified: 25 July 2005, 15:52:08 > So it's past midnight here, and I had to make sure some wine used by my GF for cooking is good, so I don't have time to track down the precise meaning of this problem. Broadly speaking, however, it goes something like this: Windows suck. More specifically, while FILETIME is DEFINED to be the number of 100-nanoseconds since January 1st, 1601, and time_t is defined to be the number of seconds since January 1st, 1970, merely converting between the two based on this information simply doesn't produce correct file times when the date falls inside a daylight saving zone. It seems that while file times are stored in some form of UTC, this is only approximately UTC, as it still shifts by an hour when going into/out of daylight saving. Unfortunately, I could not find, under the circumstances mentioned above, any good way of finding out whether a specific date is or is not daylight saving, which means that our "ft2ut" (FILETIME to Unix time_t) function is off by 1 hour for certain date ranges. There does not appear to be any sane way of solving this problem. So, instead, I decided to ignore the problem altogether. Instead of correctly converting a FILETIME to time_t, I'm converting it incorrectly, but using the precise opposite function, I manage to convert it back to the original FILETIME. This means that I'm now setting the file's time using the Win32 SetFileTime, instead of using the POSIX "utimes". Quite expectedly, there is a downside. SetFileTime will only set times over files through their file handle. In other words, in order to set the file's time, I now need to open it with GENERIC_WRITE access. This is very far from being ideal, but I suspect it's what Window's implementation of "utimes" does anyways. As far as I can tell, under my current condition, the bug is now solved. Attached is our, now famous, zia file with 1.02test2, as well as the patch file from 1.01 (i.e. - not incremental to the previous patch posted). Any feedback most welcome. Shachar |
From: Julian P. R. <jul...@gm...> - 2007-01-26 00:53:54
|
OK beat you to it... I'ts 1.30am :) I'm at home now, but was able to run a quick test and it seems the problem is indeed solved with attached exe. I had read something about windows using "Gregorian" times since 1601 for files (why ?!?) but too tired to fully digest your explanation at the time (and had to "test" some wine too) What's the downside of G_W? is it with regards to sharing while handle is open etc? Anyways thanks for all your hard work. Off to sleep. On 25/01/07, Shachar Shemesh <sh...@sh...> wrote: > > Julian Pace Ross wrote: > > > > Modified: 25 July 2005, 14:52:08 > > Modified: 25 July 2005, 14:52:08 > > Modified: 25 July 2005, 15:52:08 > > > So it's past midnight here, and I had to make sure some wine used by my > GF for cooking is good, so I don't have time to track down the precise > meaning of this problem. Broadly speaking, however, it goes something > like this: > Windows suck. > > More specifically, while FILETIME is DEFINED to be the number of > 100-nanoseconds since January 1st, 1601, and time_t is defined to be the > number of seconds since January 1st, 1970, merely converting between the > two based on this information simply doesn't produce correct file times > when the date falls inside a daylight saving zone. > > It seems that while file times are stored in some form of UTC, this is > only approximately UTC, as it still shifts by an hour when going > into/out of daylight saving. > > Unfortunately, I could not find, under the circumstances mentioned > above, any good way of finding out whether a specific date is or is not > daylight saving, which means that our "ft2ut" (FILETIME to Unix time_t) > function is off by 1 hour for certain date ranges. There does not appear > to be any sane way of solving this problem. > > So, instead, I decided to ignore the problem altogether. Instead of > correctly converting a FILETIME to time_t, I'm converting it > incorrectly, but using the precise opposite function, I manage to > convert it back to the original FILETIME. This means that I'm now > setting the file's time using the Win32 SetFileTime, instead of using > the POSIX "utimes". > > Quite expectedly, there is a downside. SetFileTime will only set times > over files through their file handle. In other words, in order to set > the file's time, I now need to open it with GENERIC_WRITE access. This > is very far from being ideal, but I suspect it's what Window's > implementation of "utimes" does anyways. > > As far as I can tell, under my current condition, the bug is now solved. > Attached is our, now famous, zia file with 1.02test2, as well as the > patch file from 1.01 (i.e. - not incremental to the previous patch > posted). > > Any feedback most welcome. > > Shachar > > > |
From: David V. <dav...@gm...> - 2007-01-26 04:27:27
|
Sachar, When, several months ago, I asked you if a windows version would be available one day, I would never imagine it would give you so much troubles. I admire the way you calmy solve the problems one after the other. David V. 2007/1/25, Julian Pace Ross <jul...@gm...>: > > OK beat you to it... I'ts 1.30am :) > I'm at home now, but was able to run a quick test and it seems the problem > is indeed solved with attached exe. > > I had read something about windows using "Gregorian" times since 1601 for > files (why ?!?) > but too tired to fully digest your explanation at the time (and had to > "test" some wine too) > > What's the downside of G_W? is it with regards to sharing while handle is > open etc? > > Anyways thanks for all your hard work. > > Off to sleep. > > > > On 25/01/07, Shachar Shemesh <sh...@sh...> wrote: > > > > Julian Pace Ross wrote: > > > > > > Modified: 25 July 2005, 14:52:08 > > > Modified: 25 July 2005, 14:52:08 > > > Modified: 25 July 2005, 15:52:08 > > > > > So it's past midnight here, and I had to make sure some wine used by my > > GF for cooking is good, so I don't have time to track down the precise > > meaning of this problem. Broadly speaking, however, it goes something > > like this: > > Windows suck. > > > > More specifically, while FILETIME is DEFINED to be the number of > > 100-nanoseconds since January 1st, 1601, and time_t is defined to be the > > number of seconds since January 1st, 1970, merely converting between the > > > > two based on this information simply doesn't produce correct file times > > when the date falls inside a daylight saving zone. > > > > It seems that while file times are stored in some form of UTC, this is > > only approximately UTC, as it still shifts by an hour when going > > into/out of daylight saving. > > > > Unfortunately, I could not find, under the circumstances mentioned > > above, any good way of finding out whether a specific date is or is not > > daylight saving, which means that our "ft2ut" (FILETIME to Unix time_t) > > function is off by 1 hour for certain date ranges. There does not appear > > to be any sane way of solving this problem. > > > > So, instead, I decided to ignore the problem altogether. Instead of > > correctly converting a FILETIME to time_t, I'm converting it > > incorrectly, but using the precise opposite function, I manage to > > convert it back to the original FILETIME. This means that I'm now > > setting the file's time using the Win32 SetFileTime, instead of using > > the POSIX "utimes". > > > > Quite expectedly, there is a downside. SetFileTime will only set times > > over files through their file handle. In other words, in order to set > > the file's time, I now need to open it with GENERIC_WRITE access. This > > is very far from being ideal, but I suspect it's what Window's > > implementation of "utimes" does anyways. > > > > As far as I can tell, under my current condition, the bug is now solved. > > Attached is our, now famous, zia file with 1.02test2, as well as the > > patch file from 1.01 (i.e. - not incremental to the previous patch > > posted). > > > > Any feedback most welcome. > > > > Shachar > > > > > > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share > your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > > _______________________________________________ > Rsyncrypto-devel mailing list > Rsy...@li... > https://lists.sourceforge.net/lists/listinfo/rsyncrypto-devel > > > |