[Xastir] win32 shapefiles

[Bryce Wolfson]

On 9/24/03 7:34 AM, "Curt Mills, WE7U" <hacker at tc.fluke.com> wrote:

> On Wed, 24 Sep 2003, J. Lance Cotton wrote:
> 
>> I have experienced problems with adding new maps that
>> don't show up and found that the solution is to use the "touch" unix command
>> to change the file modification date to 'now', at which point, the "Index:
>> Add new maps" command in Xastir would properly index the new maps. The
>> problem was that when I unzipped the map files, the unzip utility preserved
>> the files' modification date as stored in the zip file.
> 
> Correct.  We look at the timestamps on the files.  If the map index
> is newer than the map files, we don't index.  Touch tweaks the
> timestamp.
> 
> Another solution is to index all, but that can take a lot of time if
> you have a lot of maps.

---

> We look at the timestamps on the files.
> If the map index is newer than the map files, we don't index.

This seems unnecessarily fragile, especially considering that I see "Q: My
new maps aren't showing up", "A: Try touching the timestamps, or do an index
all if all else fails" every few weeks on this list.

In order to find maps that have newer timestamps than the index, you must
already be walking the entire tree and pulling the directory entry for every
file; why not, when walking the directory structure on an index update,
check for the presence of the map in the index? This alone would solve the
'new maps with timestamps before index build date' problem. As an even
better improvement, store the map's timestamp in the index as well (adds 4
bytes per map), and if a particular map _is_ already in the index (since
you're looking anyway) then check the timestamp against the one stored in
the index to see if the map's been updated and the index entry needs updated
as well.

I'm seeing a lot of user issues caused by the current behavior; this really
seems like something the software should be able to cleanly handle.

2c.

Cheers.
-Bryce