[jira] [Commented] (SANSELAN-32) ExifRewriter.updateExifMetadataLossless corrupts maker notes
[ https://issues.apache.org/jira/browse/SANSELAN-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13175282#comment-13175282 ] Damjan Jovanovic commented on SANSELAN-32: -- EXIF defines the MakeNote tag as type UNDEFINED, count Any. Canon seems to use its MakerNote as another TIFF directory, which references values with offsets relative to the beginning of the TIFF file, not the beginning of itself nor contained within itself. This means the technique used by Sanselan to copy EXIF from one file to another - parse original and write from parsed data - will fail, since it treats the MakerNote as an opaque value, yet when it is rewritten the data it was referencing will either not have been copied or will be found at different offsets in the new file. Either the entire EXIF segment must be copied as an opaque value, which will prevent any modification to it, or the MakerNote must be parsed with manufacturer-specific code. These are the only ways to prevent MakerNote corruption. > ExifRewriter.updateExifMetadataLossless corrupts maker notes > > > Key: SANSELAN-32 > URL: https://issues.apache.org/jira/browse/SANSELAN-32 > Project: Commons Sanselan > Issue Type: Bug > Environment: 0.97-incubator >Reporter: Lulu winlumski >Priority: Critical > Attachments: SanselanExifWriter.java, modified.jpg, original.jpg > > > rewriter.updateExifMetadataLossless(jpeg, os, outputSet); > lead to loss of maker notes in the attached files. > See attached files for details. > $ exiftool -Makernotes:all original.jpg > original.txt > $ exiftool -Makernotes:all modified.jpg > modified.txt > $ diff -u original.txt modified.txt > --- original.txt 2009-10-21 02:14:11.0 +0200 > +++ modified.txt 2009-10-21 02:14:15.0 +0200 > @@ -1,66 +1,8 @@ > -Focal Type : Zoom > -Focal Plane X Size : 5.84 mm > -Focal Plane Y Size : 4.39 mm > -Canon Image Type: IMG:DIGITAL IXUS 60 JPEG > -Canon Firmware Version : Firmware Version 1.00 > +Canon Image Type: > +Canon Firmware Version : > File Number : 100-0877 > Owner Name : > Canon Model ID : PowerShot SD600 / Digital IXUS 60 / IXY > Digital 70 > Thumbnail Image Valid Area : 0 0 0 0 > Date Stamp Mode : Off > -My Color Mode : Off > Firmware Revision : 1.00 rev 1.00 > -Macro Mode : Normal > -Self Timer : Off > -Quality : Superfine > -Canon Flash Mode: Red-eye reduction (Auto) > -Continuous Drive: Single > -Focus Mode : Single > -Record Mode : JPEG > -Canon Image Size: Large > -Easy Mode : Full auto > -Digital Zoom: None > -Contrast: Normal > -Saturation : Normal > -Sharpness : 0 > -Camera ISO : Auto > -Metering Mode : Evaluative > -Focus Range : Auto > -AF Point: Auto AF point selection > -Canon Exposure Mode : Easy > -Lens Type : Unknown (-1) > -Long Focal : 17.4 mm > -Short Focal : 5.8 mm > -Focal Units : 1000 > -Max Aperture: 2.8 > -Min Aperture: 5.6 > -Flash Bits : (none) > -Focus Continuous: Single > -AE Setting : Normal AE > -Zoom Source Width : 2816 > -Zoom Target Width : 2816 > -Spot Metering Mode : Center > -Manual Flash Output : n/a > -Auto ISO: 148 > -Base ISO: 100 > -Measured EV : 4.19 > -Target Aperture : 2.8 > -Target Exposure Time: 1/60 > -Exposure Compensation : 0 > -White Balance : Auto > -Slow Shutter: Off > -Shot Number In Continuous Burst : 0 > -Optical Zoom Code : 0 > -Flash Guide Number : 0 > -Flash Exposure Compensation : 0 > -Auto Exposure Bracketing: Off > -AEB Bracket Value : 0 > -Control Mode: Camera Local Control > -Focus Distance Upper: 2.56 > -Focus Distance Lower: 0 > -Bulb Duration : 0 > -Camera Type : Compact > -Auto Rotate : Rotate 90 CW > -ND Filter : Off > -Self Timer
[jira] [Resolved] (COMPRESS-169) RuntimeException on corrupted file
[
https://issues.apache.org/jira/browse/COMPRESS-169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Bodewig resolved COMPRESS-169.
-
Resolution: Fixed
Fix Version/s: 1.4
fixed with svn revision 1222360
I've put giving the TIKA hardener a try on my TODO list, but that's not really
too short anyway.
Thanks!
> RuntimeException on corrupted file
> --
>
> Key: COMPRESS-169
> URL: https://issues.apache.org/jira/browse/COMPRESS-169
> Project: Commons Compress
> Issue Type: Bug
>Affects Versions: 1.3
>Reporter: Jerome Lacoste
>Priority: Minor
> Fix For: 1.4
>
>
> We wrote a tool to simulate file corruption before parsing them with tika.
> This caused a few strange problems including:
> {code}
> java.lang.RuntimeException: failed to skip file name in local file header
> at
> org.apache.commons.compress.archivers.zip.ZipFile.resolveLocalFileHeaderData(ZipFile.java:817)
> at
> org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:207)
> at
> org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:181)
> at
> org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:142)
> at
> org.apache.tika.parser.pkg.ZipContainerDetector.detect(ZipContainerDetector.java:69)
> at
> org.apache.tika.detect.CompositeDetector.detect(CompositeDetector.java:60)
> at
> org.apache.tika.parser.AutoDetectParser.parse(AutoDetectParser.java:113)
> at org.apache.tika.Tika.parseToString(Tika.java:380)
> at org.apache.tika.Tika.parseToString(Tika.java:414)
> at
> no.finntech.tika.harderner.TikaIndexerHardenerTest.parseContent(TikaIndexerHardenerTest.java:106)
> at
> no.finntech.tika.harderner.TikaIndexerHardenerTest.flipBitAndIndexContent(TikaIndexerHardenerTest.java:89)
> at
> no.finntech.tika.harderner.TikaIndexerHardenerTest.originalFileIndexesProperly4(TikaIndexerHardenerTest.java:34)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runNotIgnored(BlockJUnit4ClassRunner.java:79)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:71)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:49)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:157)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:71)
> at
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:202)
> at
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:63)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at com.intellij.rt.execution.application.AppMain.main(AppMain.java:120)
> {code}
> This is caused by:
> {code}
> while (lenToSkip > 0) {
> int skipped = archive.skipBytes(lenToSkip);
> if (skipped <= 0) {
> throw new RuntimeException("failed to skip file name in"
>+ " local file header");
> }
> lenToSkip -= skipped;
> }
> {code}
> Any reason this is using a RuntimeException instead of a IOException ?
> Changing it to a IOE would solve our problem.
> Finally, our test code is available from
> https://github.com/lacostej/tika-hardener
> You might want to reuse similar technique for
[jira] [Commented] (COMPRESS-168) getName of ZipArchiveEntry
[ https://issues.apache.org/jira/browse/COMPRESS-168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13174900#comment-13174900 ] Stefan Bodewig commented on COMPRESS-168: - Any news? > getName of ZipArchiveEntry > -- > > Key: COMPRESS-168 > URL: https://issues.apache.org/jira/browse/COMPRESS-168 > Project: Commons Compress > Issue Type: Test > Components: Archivers >Affects Versions: 1.2 > Environment: J2EE Environment with jdk 1.4 >Reporter: Pavithra Kumar > Attachments: TestZip.zip > > > getName method of ZipArchiveEntry is not giving arabic file names. Instead of > that it gives some chunked characters. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (IO-279) Tailer erroneously consider file as new
[
https://issues.apache.org/jira/browse/IO-279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13174800#comment-13174800
]
Sergio Bossa commented on IO-279:
-
Mark, that should be fixed in my fork: https://github.com/sbtourist/tayler
> Tailer erroneously consider file as new
> ---
>
> Key: IO-279
> URL: https://issues.apache.org/jira/browse/IO-279
> Project: Commons IO
> Issue Type: Bug
>Affects Versions: 2.0.1
>Reporter: Sergio Bossa
>
> Tailer sometimes erroneously consider the tailed file as new, forcing a
> repositioning at the start of the file: I'm still unable to reproduce this in
> a test case, because it only happens to me with huge log files during Apache
> Tomcat startup.
> This is the piece of code causing the problem:
> // See if the file needs to be read again
> if (length > position) {
> // The file has more content than it did last time
> last = System.currentTimeMillis();
> position = readLines(reader);
> } else if (FileUtils.isFileNewer(file, last)) {
> /* This can happen if the file is truncated or overwritten
> * with the exact same length of information. In cases like
> * this, the file position needs to be reset
> */
> position = 0;
> reader.seek(position); // cannot be null here
> // Now we can read new lines
> last = System.currentTimeMillis();
> position = readLines(reader);
> }
> What probably happens is that the new file content is about to be written on
> disk, the date is already updated but content is still not flushed, so actual
> length is untouched and there you go.
> In other words, I think there should be some better method to verify the
> condition above, rather than relying only on dates: keeping and comparing the
> hash code of the latest line may be a solution, but may hurt performances ...
> other ideas?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (IO-279) Tailer erroneously consider file as new
[
https://issues.apache.org/jira/browse/IO-279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13174763#comment-13174763
]
Mark Baker commented on IO-279:
---
I see this bug as well, I am using this class to tail log files during a
lengthly build process and occasionally the entire log file will be
regurgitated :(
> Tailer erroneously consider file as new
> ---
>
> Key: IO-279
> URL: https://issues.apache.org/jira/browse/IO-279
> Project: Commons IO
> Issue Type: Bug
>Affects Versions: 2.0.1
>Reporter: Sergio Bossa
>
> Tailer sometimes erroneously consider the tailed file as new, forcing a
> repositioning at the start of the file: I'm still unable to reproduce this in
> a test case, because it only happens to me with huge log files during Apache
> Tomcat startup.
> This is the piece of code causing the problem:
> // See if the file needs to be read again
> if (length > position) {
> // The file has more content than it did last time
> last = System.currentTimeMillis();
> position = readLines(reader);
> } else if (FileUtils.isFileNewer(file, last)) {
> /* This can happen if the file is truncated or overwritten
> * with the exact same length of information. In cases like
> * this, the file position needs to be reset
> */
> position = 0;
> reader.seek(position); // cannot be null here
> // Now we can read new lines
> last = System.currentTimeMillis();
> position = readLines(reader);
> }
> What probably happens is that the new file content is about to be written on
> disk, the date is already updated but content is still not flushed, so actual
> length is untouched and there you go.
> In other words, I think there should be some better method to verify the
> condition above, rather than relying only on dates: keeping and comparing the
> hash code of the latest line may be a solution, but may hurt performances ...
> other ideas?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
