Bugzilla – Full Text Bug Listing
| Summary: | Import local file... silently overwrites destination | ||
|---|---|---|---|
| Product: | [ECD] Orion | Reporter: | Mike Wilson <Mike_Wilson> |
| Component: | Client | Assignee: | Project Inbox <orion.client-inbox> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | ahunter.eclipse, libingw |
| Version: | unspecified | Flags: | ahunter.eclipse:
review?
(john.arthorne) |
| Target Milestone: | 7.0 | ||
| Hardware: | PC | ||
| OS: | Mac OS X | ||
| Whiteboard: | |||
|
Description
Mike Wilson
When you import a zip file and select to unzip, the ClientImport support on the server checks for existing files and prompts to overwrite. I have updated ClientImport.completeMove() to use this same logic done by ClientImport.completeUnzip(). As a result, when the file exists, the user is prompted: Failed to transfer the file to [FILE], the existing file could not be overwritten Would you like to retry the import with force overwriting? If the user selects ok, the file will be overwritten. As a result of the server change, there is no changes needed to the client code since we use the existing support that the zip files take advantage of. The changes are at: https://github.com/ahunter-orion/orion.server/commit/b5365063b77e13f32491fb08c7bb3cbcc2c075ff I assert that I authored 100% of the content of this contribution and have the rights to donate the content to Eclipse under the EPL In our other API we use a header like this to indicate that the request should not overwrite: X-Xfer-Options: no-overwrite See ProtocolConstants.OPTION_NO_OVERWRITE and the various references. So the expectation is that overwrite will occur unless told otherwise. Zip import should be consistent with this. A header is easier for the client to use because they don't have to do any direct URL manipulation and avoids colliding with any existing query on the resource. Also can you add a regression test for this. See TransferTest.java. (In reply to comment #2) > In our other API we use a header like this to indicate that the request > should not overwrite: > > X-Xfer-Options: no-overwrite > > See ProtocolConstants.OPTION_NO_OVERWRITE and the various references. So the > expectation is that overwrite will occur unless told otherwise. Zip import > should be consistent with this. > > A header is easier for the client to use because they don't have to do any > direct URL manipulation and avoids colliding with any existing query on the > resource. > > Also can you add a regression test for this. See TransferTest.java. ok, both import local file and import local zip file must have been written before the File API was finalized and both need to be updated to use those API headers. (In reply to Anthony Hunter from comment #3) > (In reply to comment #2) > > In our other API we use a header like this to indicate that the request > > should not overwrite: > > > > X-Xfer-Options: no-overwrite > > > > See ProtocolConstants.OPTION_NO_OVERWRITE and the various references. So the > > expectation is that overwrite will occur unless told otherwise. Zip import > > should be consistent with this. > > > > A header is easier for the client to use because they don't have to do any > > direct URL manipulation and avoids colliding with any existing query on the > > resource. > > > > Also can you add a regression test for this. See TransferTest.java. > > ok, both import local file and import local zip file must have been written > before the File API was finalized and both need to be updated to use those > API headers. Client change: https://git.eclipse.org/r/#/c/33841/ Sever change: https://git.eclipse.org/r/#/c/33840/ Bug was assigned to an inactive contributor. Moving back to inbox. |