1) When I started investigating this issue I found that I had mischaracterized the bug: GeoServer is not rewriting Shapefiles when they already exist, it is deleting them as part of the upload process. The reason is that GeoServer determines the filename for uploads based on the workspace, store, and "format" as specified in the URL - when you upload a ZIP archive to /workspaces/ws/datastores/ds/file.shp (the cue to GeoServer that this is a ZIP archive is in the HTTP headers, not the URL) this comes out to ws/ds/ds.zip . GeoServer does this in the data directory and not a temporary directory, so any time you upload a zipped shapefile to a directory store that already contains a shapefile whose name matches the store, it detects a conflict - and responds by deleting all files in the directory. You can verify this behavior against the default data directory by using curl and a couple of zipped shapefiles:
curl -T world.zip -u admin:geoserver http:
Significantly, the shapefile inside world.zip should also be named world.shp (etc.) After this is uploaded, uploading a shapefile with any filename to the world/ datastore will delete all files in the datastore.
The code in this branch attempts to identify cases where we're not actually writing the literal uploaded data into the data directory (zip files which are temporary, and any upload that's being translated to a new format) and use /tmp/ for the temporary stuff, reducing the frequency of conflicts in general and avoiding spurious conflicts being detected like the one described above.
2) Can't argue with you about the name changes; I'll see about splitting these out. I find it really difficult to follow the existing code though, ok with you if I make some refactoring commits before the functional changes?
3) Some of the modifications in this branch are moving into the schema matching stuff I discussed on the list, I guess this should be a separate issue/patchset.