Task #10727 (closed)
RFE: Make ChecksumProvider resilient to zero-length files
| Reported by: | bpindelski | Owned by: | mtbcarroll |
|---|---|---|---|
| Priority: | major | Milestone: | 5.0.0-beta1 |
| Component: | Services | Version: | n.a. |
| Keywords: | n.a. | Cc: | bpindelski, jamoore |
| Resources: | n.a. | Referenced By: | n.a. |
| References: | n.a. | Remaining Time: | 0.0d |
| Sprint: | n.a. |
Description
It has been discovered, that when a 0 byte file is passed to a ChecksumProvider? instance, it returns null. There is a unit test for zero-length byte arrays, but not empty files. Correct and fix code.
Change History (11)
comment:1 Changed 11 years ago by mtbcarroll
comment:2 Changed 11 years ago by bpindelski
mtbcarroll: Your questions make sense, but I'd like to not start a discussion here. I'd like to make the checksum API handle the most common use cases and leave for the caller to handle more exotic accidents.
comment:3 Changed 11 years ago by jamoore
bpindelski: +1 on a non null for zero-length files. E.g.
touch /tmp/empty && shasum /tmp/empty da39a3ee5e6b4b0d3255bfef95601890afd80709 /tmp/empty
Mark, could you open a separate RFE with your comment?
comment:4 Changed 11 years ago by mtbcarroll
comment:5 Changed 11 years ago by bpindelski
- Summary changed from RFE: Make CheksumProvider resilient to zero-length files to RFE: Make ChecksumProvider resilient to zero-length files
comment:6 Changed 11 years ago by bpindelski
I think there is still one place that is causing exceptions on dev_4_4. OMEROGateway.java has still "pending" strings set as SHA1 files (in the OriginalFile upload(SecurityContext ctx, File file, String mimeType, long originalFileID) method. Try attaching a zero-length file annotation to a P/D/I in Insight. That will cause a checksum mismatch. Quick tests have showed that using the provider for checksum calculation solves the issue. Should be easy to fix.
comment:7 Changed 11 years ago by bpindelski
- Cc bpindelski added; mtbcarroll removed
- Owner changed from bpindelski to mtbcarroll
comment:8 Changed 11 years ago by mtbcarroll
Note https://github.com/openmicroscopy/openmicroscopy/pull/1047 in case the fix to this affects that.
comment:9 Changed 11 years ago by mtbcarroll
- Resolution set to fixed
- Status changed from new to closed
comment:10 Changed 11 years ago by Mark Carroll <m.t.b.carroll@…>
- Remaining Time set to 0
(In [324ed89e4052e7031b913b6909abcd092b76c49b/ome.git] on branch develop) fix #10727, so raw file bean can create empty files
comment:11 Changed 11 years ago by Josh Moore <josh@…>
(In [cfcb214f74a3da343b43f918e833f46fd02e60d6/ome.git] on branch develop) Merge pull request #1103 from mtbc/trac-10727
fix #10727, so raw file bean can create empty files (rebased)
There are interesting questions about the intended API here. When should the raw file store create an empty file (probably not if a client is just trying to read a non-existent file)? When must we distinguish between an empty file and an absent file? Etc.