Thread: Re: Please verify 1.01 (Page 2)
Brought to you by:
thesun
From: Shachar S. <sh...@sh...> - 2007-01-26 07:25:28
|
Julian Pace Ross wrote: > I'm at home now, but was able to run a quick test and it seems the > problem is indeed solved with attached exe. Drunken coding at its best! > 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) Mine was very good (and I'm not talking about http://www.winehq.org). > What's the downside of G_W? is it with regards to sharing while handle > is open etc? Not at all. The downside is that the time in which the file was modified changes if you switch timezones. Let's give an example. First, how this works on Linux. I have three files. "1"'s date is set to 9:00am today, 2 to 9:00am on March 25th (my 34th birthday), and 3 to 9:00am on August 1st (the day we move in to our new apartment). All times are in the Israeli time zone: > $ ls -l > total 0 > -rw-r--r-- 1 sun sun 0 2007-01-26 09:00 1 > -rw-r--r-- 1 sun sun 0 2007-03-25 09:00 2 > -rw-r--r-- 1 sun sun 0 2007-08-01 09:00 3 I can also ask to view those very same files in the UTC timezone: > $ TZ=UTC ls -l > total 0 > -rw-r--r-- 1 sun sun 0 2007-01-26 07:00 1 > -rw-r--r-- 1 sun sun 0 2007-03-25 07:00 2 > -rw-r--r-- 1 sun sun 0 2007-08-01 06:00 3 Notice how 1 and 2 moved two hours back, but 3 moved three hours back. That's because August 1st is a DST time in Israel, and is therefor UTC+3, and not UTC+2. Now let's look at all three files in the Malta time zone: > $ TZ=Europe/Malta ls -l > total 0 > -rw-r--r-- 1 sun sun 0 2007-01-26 08:00 1 > -rw-r--r-- 1 sun sun 0 2007-03-25 09:00 2 > -rw-r--r-- 1 sun sun 0 2007-08-01 08:00 3 Malta is usually UTC+1, except when summer time is active, at which time it is UTC+2. My birthday, at least this year, is in summer time in Malta (UTC+2), but not in Israel (also UTC+2), and therefor shows the same time in both timezones. Today is Summer time in neither (therefor showing one hour difference), and I move into my new apartment when there is summer time in both (also showing a one hour difference). The same files can be looked at from different time zones, and the times are correct, because Unix, fundamentally, stores dates in UTC, which doesn't have summer time. Now let's try the same trick on Windows..... > F:\tst>dir > Volume in drive F has no label. > Volume Serial Number is 68D6-F941 > > Directory of F:\tst > > 01/26/2007 09:18a <DIR> . > 01/26/2007 09:18a <DIR> .. > 01/26/2007 09:00a 0 1 > 03/25/2007 09:00a 0 2 > 08/01/2007 09:00a 0 3 > 3 File(s) 0 bytes > 2 Dir(s) 7,740,653,568 bytes free So our files, in Israeli time zone, are ok. Great. let's change our timezone to Malta: > Volume in drive F has no label. > Volume Serial Number is 68D6-F941 > > Directory of F:\tst > > 01/26/2007 08:18a <DIR> . > 01/26/2007 08:18a <DIR> .. > 01/26/2007 08:00a 0 1 > 03/25/2007 08:00a 0 2 > 08/01/2007 08:00a 0 3 > 3 File(s) 0 bytes > 2 Dir(s) 7,740,653,568 bytes free Oops. 1 and 3 have the correct time. 2, however, does not. Instead of staying at 9:00am, it switched to 8:00am along with the other files. Why? Because Windows has no notion of "DST" in file times. No matter how you look at it, it's plain wrong. A file created on March 25th 2007 at 9:00am Israeli time was NOT created at 8:00am Malta time. Please notice I did not run any custom made programs. I only used the Windows tools to look at pre-existing files. Shachar |
From: Shachar S. <sh...@sh...> - 2007-01-26 07:41:52
|
David V. wrote: > Sachar, > > When, several months ago, Being as it is that version 0.14, the first Windows version, was released on May 19th, 2005, I believe it must have been at least a year and a half ago that you asked that. It's not that I was particularly active on rsyncrypto (or anything else) this past year. Going through chemotherapy will do that to you almost any time. > 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. <open source rant> Rsyncrypto is developed as part of a larger service provided by Lingnu Open Source Consulting (my company). On the face of it, open sourcing the core technology behind a commercial service is a stupid business practice. The core algorithm was definitely patent-worthy. Standalone users of rsyncrypto are less likely to buy backup services from Lingnu. Competitors that have not done so yet are more likely to develop competing technologies. You may ask yourself why do it. Some would say "parallel development effort". The simple reality is that rsyncrypto has had zero code contributions from anyone not on my payroll. We have had some bug-bounty style money contribution, but not nearly as much as we would had we went ahead and sold the program. However, the current thread with Julian is a perfect example of the purely economical benefits from open sourcing technologies used in commercial products. Rsyncrypto is used in a very delicate position, and Lingnu is too small a company to afford a proper QA team. A failure to decrypt backed up data during a critical failure at a client's can bring about a law suite that might put Lingnu cleanly out of business. The way I see it, this is the tradeoff. You get this technology for absolutely nothing, and Lingnu gets free enthusiastic user base which allows it to claim with confidence that the core technology used in its backup product is safe, tested and (relatively) widely deployed (over 100 users, judging from what little statistics can be gathered about open source products). In other words, when Julian reports a malfunction, or when you ask for more features, you are not bugging me about a problem you have. Focused reproducible bug reports are the way you repay me for releasing the technology. </open source rant> > David V. Shachar |
From: Julian P. R. <jul...@gm...> - 2007-01-26 10:26:42
|
re. Time: Thanks for the explanation. Understood perfectly. re. Open source: Glad to help with QA at any time. Also I'd be interested in writing a GUI wrapper around rsyncrypto, (maybe with .net judging from the amount of Win clients we have.. not particularly enthusiastic about java)... but that will not be anytime soon. Anyway, once the bugs are more or less out of the way, I have a couple of things on my wishlist for "Version 2". Not sure how intensive they are, but on the face of it, they dont seem to be: 1) an "rsync style --dry-run" argument 2) an end of operation summary, of the type "de/encrypted x bytes in y files", the sizes relating always to the plaintext or something like that. As you can see, both would lend themselves to a more intuitive hypothetical GUI... Cheers On 26/01/07, Shachar Shemesh <sh...@sh...> wrote: > > David V. wrote: > > Sachar, > > > > When, several months ago, > Being as it is that version 0.14, the first Windows version, was > released on May 19th, 2005, I believe it must have been at least a year > and a half ago that you asked that. It's not that I was particularly > active on rsyncrypto (or anything else) this past year. Going through > chemotherapy will do that to you almost any time. > > 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. > <open source rant> > Rsyncrypto is developed as part of a larger service provided by Lingnu > Open Source Consulting (my company). On the face of it, open sourcing > the core technology behind a commercial service is a stupid business > practice. The core algorithm was definitely patent-worthy. Standalone > users of rsyncrypto are less likely to buy backup services from Lingnu. > Competitors that have not done so yet are more likely to develop > competing technologies. You may ask yourself why do it. > > Some would say "parallel development effort". The simple reality is that > rsyncrypto has had zero code contributions from anyone not on my > payroll. We have had some bug-bounty style money contribution, but not > nearly as much as we would had we went ahead and sold the program. > > However, the current thread with Julian is a perfect example of the > purely economical benefits from open sourcing technologies used in > commercial products. Rsyncrypto is used in a very delicate position, and > Lingnu is too small a company to afford a proper QA team. A failure to > decrypt backed up data during a critical failure at a client's can bring > about a law suite that might put Lingnu cleanly out of business. The way > I see it, this is the tradeoff. You get this technology for absolutely > nothing, and Lingnu gets free enthusiastic user base which allows it to > claim with confidence that the core technology used in its backup > product is safe, tested and (relatively) widely deployed (over 100 > users, judging from what little statistics can be gathered about open > source products). > > In other words, when Julian reports a malfunction, or when you ask for > more features, you are not bugging me about a problem you have. Focused > reproducible bug reports are the way you repay me for releasing the > technology. > </open source rant> > > David V. > 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 > |