Upload to existing featuretype: Behavior is dependent on backing store type

getting started on a fix for this... here's my patch-in-progress. https://github.com/dwins/geoserver/compare/stable...geos-5056

so far i've just been working on better tempfile handling (storing temporary data outside the data directory instead of potentially overwriting user data during uploads.) Still on the queue:

• testing explicitly for file conflicts during zipfile extraction
• check for featuretype conflicts before copying any featuretypes (instead of one-by-one)
• give the coverage handling a review also

Did an initial review of the patch and am finding it hard to follow what exactly it is doing... i am still lacking some context here. Any chance you can:

1. define exactly what the scope of the patch is in terms of what has to change?
2. avoid non-meaningful changes to things like variable names, etc... i am fine with those but they just add cruft to the patch, please do them later after the fact in a separate change.

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://localhost:8080/geoserver/rest/workspaces/topp/datastores/world.shp -H 'Content-Type: application/zip'

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.

I started on untangling the changes in this branch. This branch on my github fork has a couple of the corrections that aren't really related to the original issue on this ticket:

https://github.com/dwins/geoserver/compare/stable...restconfig-bugs

I put some notes in the commit messages for your review.

https://github.com/dwins/geoserver/compare/stable...geos-5056 now contains a failing test for the basic flaw I found when investigating this issue. Uploading to a file-based store when the data dir contains a file whose name matches the datastore name will delete any files in the store's directory.