Task #10763 (new)
Opened 11 years ago
Last modified 11 years ago
Bug: Creation of zipfile/ome-tiff attachments by file export
Reported by: | rleigh | Owned by: | web-team@… |
---|---|---|---|
Priority: | minor | Milestone: | Unscheduled |
Component: | Web | Version: | n.a. |
Keywords: | n.a. | Cc: | |
Resources: | n.a. | Referenced By: | n.a. |
References: | n.a. | Remaining Time: | n.a. |
Sprint: | n.a. |
Description
Currently, export of files by the webclient [and it looks like Insight as well] results in the exported file (or files) being attached to the original image. There are several problems here:
- wasting of potentially vast quantities of storage; potentially duplicating all data, once or several times over
- there is no cleanup of the attachments, so the space used is never reclaimed
- it's contrary to the expectations of the user that their action will just download the data; implicit creating of the attachments is not obvious (particularly in Insight when you're not warned about it).
- the attachment is broken due to only being attached to one of the set being exported, rather than all images being exported.
It would be better if this generated data were only present transiently (i.e. cleaned up automatically), and was not directly attached to any of the images. Could this be stored elsewhere and automatically get cleaned up after the export is complete? In the case where we are exporting single files in their native format i.e. PNG/JPEG/TIFF, the original files could be transferred directly, or packed directly into a zip if there are multiple files [for FS].
Regards,
Roger
Change History (1)
comment:1 Changed 11 years ago by rleigh
- Component changed from General to Web
- Owner set to web-team@…