Re: cvs commit: ant/src/etc/testcases/taskdefs checksum.xml

[Antoine Levy-Lambert]

Hello Martijn,
if you have the time to do it the file comparison function that ignores 
line endings sounds good.

Cheers,
Antoine
Martijn Kruithof wrote:
Hi
I actually used the same technique as proposed in the bug report on 
the  recorder test cases. Stefan modified that one in such a way that 
not the files from cvs are "fixed" but copies of those files. I would 
propose to either go the same way here or take a better approach in 
actually write a new file comparison function that has the ability to 
ignore differences in line endings and use that one for most test cases.

Kind Regards, Martijn

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: cvs commit: ant/src/etc/testcases/taskdefs checksum.xml

[Jesse Glick]

Kev Jackson wrote:
If this is related to MD5 checksums, they've recently been proven to
not be conclusive proof that the content of the file is the same as
the checksum, ie two different files can create the same checksum
under certain conditions.
Maybe it would be a good idea to add a warning to the  doc 
page that MD5 is now widely thought to be weak, and anyone serious about 
security should consider (at least) SHA-1?

-J.
--
Jesse Glick  x22801
NetBeans, Open APIs  
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: cvs commit: ant/src/etc/testcases/taskdefs checksum.xml

[Martijn Kruithof]

Kev Jackson wrote:
If this is related to MD5 checksums, they've recently been proven to 
not be conclusive proof that the content of the file is the same as 
the checksum, ie two different files can create the same checksum 
under certain conditions.
Yes it is.
Martijn
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: cvs commit: ant/src/etc/testcases/taskdefs checksum.xml

[Martijn Kruithof]

Stefan Bodewig wrote:
On Wed, 8 Dec 2004, Matt Benson <[EMAIL PROTECTED]> wrote:
 

Hmm... maybe we should just change the unit test to read the files
(using  with a  filter) into properties
and compare those rather than using FileUtils.contentEquals(...)?
   

 

We could also add a FileUtil.contentEquals(...) variant that ignores 
differences in line endings.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: cvs commit: ant/src/etc/testcases/taskdefs checksum.xml

[Kev Jackson]

If this is related to MD5 checksums, they've recently been proven to not 
be conclusive proof that the content of the file is the same as the 
checksum, ie two different files can create the same checksum under 
certain conditions.

Not sure if this is relevant to the discussion
http://developers.slashdot.org/article.pl?sid=04/12/07/2019244&tid=93&tid=172&tid=8
"/we can create 'doppelganger' blocks (my term) anywhere inside a file 
that may be swapped out, one for another, without altering the final MD5 
hash. This lets us create any number of binary-inequal files with the 
same md5sum. But MD5 uses an appendable cascade construction -- in other 
words, if you happen to find yourself with two files that MD5 to the 
same hash, an arbitrary payload can be applied to both files and they'll 
still have the same hash."/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: cvs commit: ant/src/etc/testcases/taskdefs checksum.xml

[Stefan Bodewig]

On Wed, 08 Dec 2004, Martijn Kruithof <[EMAIL PROTECTED]> wrote:

> I actually used the same technique as proposed in the bug report on
> the recorder test cases. Stefan modified that one in such a way that
> not the files from cvs are "fixed" but copies of those files.

I mainly did so since otherwise you modify your working copy (at least
if the original line endings when the files have been checked in are
different from your local platform).  We shouldn't change the files
we've checked out.  We already modify the timestamp of jar.xml on each
testrun and CVS thinks it has been changed until you do the next
"cvs up".

Stefan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: cvs commit: ant/src/etc/testcases/taskdefs checksum.xml

[Stefan Bodewig]

On Wed, 8 Dec 2004, Dominique Devienne <[EMAIL PROTECTED]> wrote:

> Isn't the alternative simply to check in the expected files are
> binary to avoid line ending conversions at all?

Won't work since the result of running  produces platfirm
dependent line ends.

Stefan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: cvs commit: ant/src/etc/testcases/taskdefs checksum.xml

[Stefan Bodewig]

On Wed, 8 Dec 2004, Matt Benson <[EMAIL PROTECTED]> wrote:

> Hmm... maybe we should just change the unit test to read the files
> (using  with a  filter) into properties
> and compare those rather than using FileUtils.contentEquals(...)?

+1

Stefan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: cvs commit: ant/src/etc/testcases/taskdefs checksum.xml

[Martijn Kruithof]

Hi
I actually used the same technique as proposed in the bug report on the  
recorder test cases. Stefan modified that one in such a way that not the 
files from cvs are "fixed" but copies of those files. I would propose to 
either go the same way here or take a better approach in actually write 
a new file comparison function that has the ability to ignore 
differences in line endings and use that one for most test cases.

Kind Regards, Martijn
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: cvs commit: ant/src/etc/testcases/taskdefs checksum.xml

[Matt Benson]

--- Dominique Devienne <[EMAIL PROTECTED]> wrote:

> Isn't the alternative simply to check in the
> expected files are binary to avoid line ending
> conversions at all? Just thinking out loud. --DD

Maybe, but that at least puts us back to the fixcrlf
fix since the output files are being written with the
system line separator.

-Matt



__ 
Do you Yahoo!? 
Yahoo! Mail - Find what you need with new enhanced search.
http://info.mail.yahoo.com/mail_250

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: cvs commit: ant/src/etc/testcases/taskdefs checksum.xml

[Dominique Devienne]

Isn't the alternative simply to check in the expected files are binary to avoid 
line ending conversions at all? Just thinking out loud. --DD



From: Matt Benson [mailto:[EMAIL PROTECTED]
Sent: Wed 12/8/2004 11:36 AM
To: Ant Developers List
Subject: Re: cvs commit: ant/src/etc/testcases/taskdefs checksum.xml



Hey, good point, I follow you... if the cvs client
auto-converts the "expected" files, then they won't
match the 'd files.  Hmm... maybe we should
just change the unit test to read the files (using
 with a  filter) into
properties and compare those rather than using
FileUtils.contentEquals(...)?  Any other ideas?

-Matt

--- Peter Reilly <[EMAIL PROTECTED]> wrote:

> Actually, I have had a quick look at the changes you
> made.
> I do not believe that they will work on windows with
> a dos style cvs client.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: cvs commit: ant/src/etc/testcases/taskdefs checksum.xml

[Matt Benson]

--- Matt Benson <[EMAIL PROTECTED]> wrote:
[SNIP]
> match the 'd files.  Hmm... maybe we should
> just change the unit test to read the files (using
>  with a  filter) into
> properties and compare those rather than using
> FileUtils.contentEquals(...)?  Any other ideas?
[SNIP]

I will go ahead and commit this as a better
alternative to breaking "true Windows" CVS clients
until something better comes along.

-Matt




__ 
Do you Yahoo!? 
Yahoo! Mail - You care about security. So do we. 
http://promotions.yahoo.com/new_mail

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: cvs commit: ant/src/etc/testcases/taskdefs checksum.xml

[Peter Reilly]

That sounds like a good idea.
Peter
Matt Benson wrote:
Hey, good point, I follow you... if the cvs client
auto-converts the "expected" files, then they won't
match the 'd files.  Hmm... maybe we should
just change the unit test to read the files (using
 with a  filter) into
properties and compare those rather than using
FileUtils.contentEquals(...)?  Any other ideas?
-Matt
 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: cvs commit: ant/src/etc/testcases/taskdefs checksum.xml

[Matt Benson]

Hey, good point, I follow you... if the cvs client
auto-converts the "expected" files, then they won't
match the 'd files.  Hmm... maybe we should
just change the unit test to read the files (using
 with a  filter) into
properties and compare those rather than using
FileUtils.contentEquals(...)?  Any other ideas?

-Matt

--- Peter Reilly <[EMAIL PROTECTED]> wrote:

> Actually, I have had a quick look at the changes you
> made.
> I do not believe that they will work on windows with
> a dos style cvs client.
> 
> For example:
> the xml target is now:
>   
>  />
>  includes="asf-logo.gif.MD5" />
>   
> the test is:
> 
> public void testCreateMd5() throws IOException {
> FileUtils fileUtils =
> FileUtils.newFileUtils();
> executeTarget("createMd5");
> 
>
assertTrue(fileUtils.contentEquals(project.resolveFile("expected/asf-logo.gif.md5"),
>
> project.resolveFile("../asf-logo.gif.MD5")));
> }
> 
> The expected file is  "expected/asf-logo.gif.md5".
> There will be a one 
> character
> difference between the size of the file with dos
> line ending and a file 
> with unix (or mac) line
> endings. With the change you make, the test will not
> compare a file with 
> dos line endings
> to one with unix lineending and so will fail.
> 
> Peter
> 
> 
> Matt Benson wrote:
> 
> >--- Stefan Bodewig <[EMAIL PROTECTED]> wrote:
> >
> >  
> >
> >>On Wed, 08 Dec 2004, Peter Reilly
> >><[EMAIL PROTECTED]> wrote:
> >>
> >>
> >>
> >>>I think it is more a cvs client issue.  Some cvs
> >>>  
> >>>
> >>clients on windows
> >>
> >>
> >>>convert to dos endings (correct behaviour for
> >>>  
> >>>
> >>non-binary files) and
> >>
> >>
> >>>some do not (cygwin cvs client I think does not).
> >>>  
> >>>
> >>Still, if it worked before ...
> >>
> >>
> >>
> >Hmmm... Peter is right, I do use the cygwin cvs
> client
> >on Windows.  But again, if it worked before... if
> it's
> >a cygwin issue it possibly is dependent on the fact
> >that I have un*x selected as my default filetype. 
> >Anyway...
> >
> >-Matt
> >
> >  
> >
> >>Stefan
> >>
> >>
> >>
> >>
>
>-
> >  
> >
> >>To unsubscribe, e-mail:
> >>[EMAIL PROTECTED]
> >>For additional commands, e-mail:
> >>[EMAIL PROTECTED]
> >>
> >>
> >>
> >>
> >
> >
> >
> > 
> >__ 
> >Do you Yahoo!? 
> >Meet the all-new My Yahoo! - Try it today! 
> >http://my.yahoo.com 
> > 
> >
> >
>
>-
> >To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> >For additional commands, e-mail:
> [EMAIL PROTECTED]
> >
> >
> >
> >  
> >
> 
> 
>
-
> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
> 
> 





__ 
Do you Yahoo!? 
The all-new My Yahoo! - Get yours free! 
http://my.yahoo.com 
 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: cvs commit: ant/src/etc/testcases/taskdefs checksum.xml

[Peter Reilly]

Actually, I have had a quick look at the changes you made.
I do not believe that they will work on windows with
a dos style cvs client.
For example:
the xml target is now:
 
   
   
 
the test is:
   public void testCreateMd5() throws IOException {
   FileUtils fileUtils = FileUtils.newFileUtils();
   executeTarget("createMd5");
   
assertTrue(fileUtils.contentEquals(project.resolveFile("expected/asf-logo.gif.md5"),
  
project.resolveFile("../asf-logo.gif.MD5")));
   }

The expected file is  "expected/asf-logo.gif.md5". There will be a one 
character
difference between the size of the file with dos line ending and a file 
with unix (or mac) line
endings. With the change you make, the test will not compare a file with 
dos line endings
to one with unix lineending and so will fail.

Peter
Matt Benson wrote:
--- Stefan Bodewig <[EMAIL PROTECTED]> wrote:
 

On Wed, 08 Dec 2004, Peter Reilly
<[EMAIL PROTECTED]> wrote:
   

I think it is more a cvs client issue.  Some cvs
 

clients on windows
   

convert to dos endings (correct behaviour for
 

non-binary files) and
   

some do not (cygwin cvs client I think does not).
 

Still, if it worked before ...
   

Hmmm... Peter is right, I do use the cygwin cvs client
on Windows.  But again, if it worked before... if it's
a cygwin issue it possibly is dependent on the fact
that I have un*x selected as my default filetype. 
Anyway...

-Matt
 

Stefan
   

-
 

To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
   


		
__ 
Do you Yahoo!? 
Meet the all-new My Yahoo! - Try it today! 
http://my.yahoo.com 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: cvs commit: ant/src/etc/testcases/taskdefs checksum.xml

[Matt Benson]

--- Stefan Bodewig <[EMAIL PROTECTED]> wrote:

> On Wed, 08 Dec 2004, Peter Reilly
> <[EMAIL PROTECTED]> wrote:
> 
> > I think it is more a cvs client issue.  Some cvs
> clients on windows
> > convert to dos endings (correct behaviour for
> non-binary files) and
> > some do not (cygwin cvs client I think does not).
> 
> Still, if it worked before ...
> 
Hmmm... Peter is right, I do use the cygwin cvs client
on Windows.  But again, if it worked before... if it's
a cygwin issue it possibly is dependent on the fact
that I have un*x selected as my default filetype. 
Anyway...

-Matt

> Stefan
> 
>
-
> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
> 
> 




__ 
Do you Yahoo!? 
Meet the all-new My Yahoo! - Try it today! 
http://my.yahoo.com 
 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: cvs commit: ant/src/etc/testcases/taskdefs checksum.xml

[Stefan Bodewig]

On Wed, 08 Dec 2004, Peter Reilly <[EMAIL PROTECTED]> wrote:

> I think it is more a cvs client issue.  Some cvs clients on windows
> convert to dos endings (correct behaviour for non-binary files) and
> some do not (cygwin cvs client I think does not).

Still, if it worked before ...

Stefan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: cvs commit: ant/src/etc/testcases/taskdefs checksum.xml

[Peter Reilly]

I think it is more a cvs client issue.
Some cvs clients on windows convert to dos endings (correct behaviour 
for non-binary files)
and some do not (cygwin cvs client I think does not).

Peter
Stefan Bodewig wrote:
On 7 Dec 2004, <[EMAIL PROTECTED]> wrote:
 

 Hack to make the testcases pass.
   

Sorry, I didn't manage to follow the bug report.
Before I added pluggable output patterns to  the tests
passed without the fixcrlf, so they should still do - unless I've
broken something, which seems to be the case.
Stefan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: cvs commit: ant/src/etc/testcases/taskdefs checksum.xml

[Stefan Bodewig]

On 7 Dec 2004, <[EMAIL PROTECTED]> wrote:

>   Hack to make the testcases pass.

Sorry, I didn't manage to follow the bug report.

Before I added pluggable output patterns to  the tests
passed without the fixcrlf, so they should still do - unless I've
broken something, which seems to be the case.

Stefan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]