search

bilaldursun1 / nettopologysuite

Automatically exported from code.google.com/p/nettopologysuite
0 stars 0 forks source link

Increas robustness in DBaseFileHeader.ReadHeader() #101

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. Open a dbf file with a corrupted header with the DBasefileReader. This type 
of headers seems to pop up quite frequently. No idea which software they come 
from.

What is the expected output? What do you see instead?
either you throw an exception or you try to circumvent it. Both patches attached

What version of the product are you using? On what operating system?
nts checkout 781, windows 2k8R2

Please provide any additional information below.

2 patches attached:
increase_robustness_patch.txt: will simply reset the position of the reader to 
the assumed position.
throw_error_patch.txt: will throw at least an error if the position doesn't 
match the assumed position...

Pick your poison ;)

Original issue reported on code.google.com by samuel.v...@gmail.com on 22 Nov 2011 at 11:14

GoogleCodeExporter commented 9 years ago 
patches

Original comment by samuel.v...@gmail.com on 22 Nov 2011 at 11:15

Attachments:

GoogleCodeExporter commented 9 years ago 
What is the actual behavior of nts reading corrupted files?
Can you attach a sample of some "corrupted" data?

Original comment by diegogu...@gmail.com on 22 Nov 2011 at 11:37

GoogleCodeExporter commented 9 years ago 
The sample shapefile you sent, was it created using NTS?

Original comment by felix.ob...@netcologne.de on 28 Nov 2011 at 1:50

GoogleCodeExporter commented 9 years ago 
x felix
>No idea which software they come from.
looks that isn't data built with NTS

Original comment by diegogu...@gmail.com on 28 Nov 2011 at 2:11

GoogleCodeExporter commented 9 years ago 
No that data was not generated with NTS. I know the data is in fact wrong. But 
my problem is that NTS doesn't complain at all and it represents the data 
completely wrong. Imho that should not be the case. If that counter does not 
match the assumed header length either NTS should complain that the file is 
corrupt or reset the counter to that assumed header length. 
As Excel, ArcGIS and others don't seem to have any problems with this file I 
would assume that the 'increase_robustness_patch.txt' isn't all that bad...

Original comment by samuel.v...@gmail.com on 28 Nov 2011 at 4:29

GoogleCodeExporter commented 9 years ago 
I just wanted to make sure we are not fixing a bug we introduced ourselves, 
without fixing the bug, too.

Original comment by felix.ob...@netcologne.de on 28 Nov 2011 at 4:38

GoogleCodeExporter commented 9 years ago 
I agree that show invalid data is a wrong thing, but your patch needs to be 
tested, so having also some sample data to check can be useful :)

Original comment by diegogu...@gmail.com on 28 Nov 2011 at 4:39

GoogleCodeExporter commented 9 years ago 
@diego: I got a sample file

Original comment by felix.ob...@netcologne.de on 28 Nov 2011 at 4:46

GoogleCodeExporter commented 9 years ago 
the data I gave you in the email does demonstrate the behavior.

Original comment by samuel.v...@gmail.com on 28 Nov 2011 at 4:46

GoogleCodeExporter commented 9 years ago 
fixed as of r782

Original comment by felix.ob...@netcologne.de on 28 Nov 2011 at 5:43