Hi Paul, On Sep 29, 2010, at 5:44 AM, seismic wrote:
> > Hi Quincey, > > > Quincey Koziol wrote: >> >> Hi Paul, >> >>> suspiciously like a large file access problem? >>> >>> I have also had a quick look at the HDF5 source code. It seems to make >>> use >>> of 'fseeko' if it is available otherwise it uses 'fseek' to position the >>> file pointer. I suspect this could be why it doesn't work on 32-bit >>> windows. >>> I believe Windows uses _fseeki64 rather than fseeko. >> >> Ah, yes, you are probably correct. I've filed a bug in our issue >> tracker >> to investigate and correct this. >> >> Thanks, >> Quincey >> >> >> _______________________________________________ >> Hdf-forum is for HDF software users discussion. >> [email protected] >> http://mail.hdfgroup.org/mailman/listinfo/hdf-forum_hdfgroup.org >> >> > > after further testing of this, I have verified that I can successfully read > past the 2GB point if the data is actually held within the HDF5 file itself. > So, it appears that the problem is confined to cases where the raw data is > held in an external file. > > Can you give me an idea of when this problem could be looked at? If it may > take some time, I need to find a workaround. Unfortunately I am confined to > using the windows platform. I would also prefer not to have to import my raw > data into an HDF file either. This was one of the attractive features of HDF > that I could use it to create a wrapper around pre-existing binary files. Can you try with the 1.8.6 release candidate: http://www.hdfgroup.uiuc.edu/ftp/pub/outgoing/hdf5/hdf5-1.8.6-pre1/ And let us know if that still has this problem? Thanks, Quincey _______________________________________________ Hdf-forum is for HDF software users discussion. [email protected] http://mail.hdfgroup.org/mailman/listinfo/hdf-forum_hdfgroup.org
