Task #828
Story #956: Fix problems with Metacat 0.5 implementation
A newline is removed from Sci metadata on GET operation
100%
Description
We found a one byte discrepancy in GET operations on created objects. We verified that the file created on the filesystem contains a newline as the last character. When we GET the file, the newline is chopped somehow by Metacat
Related issues
History
#1 Updated by Chad Berkley about 14 years ago
- Tracker changed from Task to Bug
- Start date set to 2010-10-06
#2 Updated by Matthew Jones about 14 years ago
- Milestone set to CCI-0.6
- Parent task set to #956
- Target version deleted (
CCI-0.6)
#3 Updated by Dave Vieglais about 14 years ago
- Tracker changed from Bug to Task
#4 Updated by Chad Berkley about 14 years ago
- translation missing: en.field_remaining_hours set to 2.0
- Status changed from New to In Progress
#5 Updated by Chad Berkley about 14 years ago
- translation missing: en.field_remaining_hours changed from 2.0 to 0.0
- Status changed from In Progress to Closed
This was a problem with the mime-multipart decoding on the metacat side. fixed now.
#6 Updated by Chad Berkley about 14 years ago
After thinking I had fixed this, I ran into it again. There seems to be a problem with FileOutputStream not writing the last byte of a String (or of an OutputStream) to disk when that last byte is a white space char. The only way I could find to fix this was to append a second newline onto the end of the written text if I found that it ended with one in the first place. I tried many different ways of writing this to disk, including FileWriter, FileOutputStream and IOUtils.copy and they all trimmed the trailing newline. Not sure what's going on there. The fix is a hack, but it works for now. If anyone has any ideas as to what's going on, let me know. The fix is in DocumentImpl.writeToFileSystem().
#7 Updated by Chad Berkley about 14 years ago
There is now a test for this in CrudServiceTest. testChecksum makes sure that the same file going into metacat also comes out of it.
