[gdal-dev] gdal file size stat test GDALOpen

mchapman at texelinc.com mchapman at texelinc.com
Sun Apr 20 21:39:48 EDT 2008


This is a tricky issue.  First of all as I understand it most drivers only read parts for the header and there for can succeed before the entire file is written.  This is really an issue outside of gdal.  

I dealt with this issue once and here is what I came up with.

1. Checking to see if the file is locked doesn't work if the ftp is asynchronous.  

2. I made a service that recursively monitored the ftp directory.

3. When a new file was detected I would check the file size, wait twenty seconds and then check the size again.  If the size was different I would wait another twenty and check again until it was the same.  Once it was the same I would process the file. 

4. Don't delete/move the original file until the process is complete in case the process fails. If it does fail it will get picked up again later and processed again.

Other that you would have to do a rasterio() call on the full source rect I imagine to unsure the entire image was there. If you do this though I would set the dest rect to be something small so you don't run out of memory.

If you think of a better way to do it please let me know your solution.


Sent via BlackBerry by AT&T

-----Original Message-----
From: Jared Rubin <JARED.RUBIN at saic.com>

Date: Sun, 20 Apr 2008 19:14:51 
To:gdal-dev at lists.osgeo.org
Subject: [gdal-dev] gdal file size stat test GDALOpen

Dear support group,
  Some of the drivers within GDAL (e.g. NITF) return success with the GDALOpen 
and GDALOpenShared calls event hough not all of the bytes of an image are on 
disk.  Is there a test to make sure that an input image is completely on disk 
before GDALOpen comes back true (some stat test?)

For example, if I am ftping a NITF image from one location to another and 
running gdalinfo on the image, gdalinfo will come back with success 
eventhough not all of the bytes are really there.

gdal-dev mailing list
gdal-dev at lists.osgeo.org

More information about the gdal-dev mailing list