TrueZIP
  1. TrueZIP
  2. TRUEZIP-319

Files are sometimes incorrectly umounted, leaving behind tmp files.

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Cannot Reproduce
    • Affects Version/s: TrueZIP 7.3.4, TrueZIP 7.4.3, TrueZIP 7.5.5, TrueZIP 7.6.6, TrueZIP 7.7, TrueZIP 7.7.1
    • Fix Version/s: None
    • Component/s: TrueZIP Kernel
    • Labels:
      None

      Description

      We're working on a product where we need to have access to zip and jar files and write to them. Unfortunately sometimes the directories wherein these live are named with archive extensions. For example:

      .../dummy.war/foo.zip/realArchive.zip
      

      But every once in so many executions the realArchive.zip is incorrectly umounted and leaved behind a realArchive.zip.XXXXXXXXX.tmp file.

      I've verified this with 7.3.4, 7.4.3 and now 7.7.1

        Activity

        Hide
        Christian Schlichtherle added a comment -

        Have you tried to call TVFS.umount(...) or TVFS.sync(...) when you are done with the processing?

        In a standalone application, TVFS.umount() gets called by an automatically managed shutdown hook, but in container environments, you may need to call one of these methods manually.

        Show
        Christian Schlichtherle added a comment - Have you tried to call TVFS.umount(...) or TVFS.sync(...) when you are done with the processing? In a standalone application, TVFS.umount() gets called by an automatically managed shutdown hook, but in container environments, you may need to call one of these methods manually.
        Hide
        jvanerp added a comment -

        Yes, I call the TFile/TFVS umount methods. Even in finally blocks, so that's not the problem. It seems like (after debugging quite some code), that after overwriting a few files using TFIleWriters (which are also closed in finally blocks), that sometimes the archive just isn't cleanly umounted, leaving behind such a tmp file.

        Show
        jvanerp added a comment - Yes, I call the TFile/TFVS umount methods. Even in finally blocks, so that's not the problem. It seems like (after debugging quite some code), that after overwriting a few files using TFIleWriters (which are also closed in finally blocks), that sometimes the archive just isn't cleanly umounted, leaving behind such a tmp file.
        Hide
        Christian Schlichtherle added a comment - - edited

        Sorry for the late answer but I have been very busy.

        I tried the following program to reproduce this issue:

        
        package com.company.mavenproject3;
        
        import de.schlichtherle.truezip.file.*;
        import java.io.*;
        
        public class HelloWorld {
            public static void main(final String[] args) throws IOException {
                final Writer writer = new TFileWriter(
                        new TFile("dummy.war/foo.zip/realAchive.zip/HälloWörld.txt"));
                try {
                    writer.write("Hello world!\n");
                } finally {
                    writer.close();
                }
            }
        }
        

        Note that I've created dummy.war and foo.zip as regular directories before running the program. I then run the program many times using JDK 1.7.0.11 and JDK 1.6.0.37 on Mac OS X 10.8.2. The result was that I cannot reproduce this issue. When I debug-step through the programm I can see that the temp file gets created upon the constructor call and unmounted in the application shutdown hook (which calls TVFS.umount()). So everything looks fine.

        I do get reports about file system errors occasionally. However, they are all from Linux and were not reproducible. TrueZIP has comprehensive multithreaded integration tests which pass with flying colors on Windows and Mac OS X, so I am led to believe that this may be an issue with the Linux port of the JDK, the OS, its file system implementation or a weird combination of all three.

        If you can provide me with a reproducible issue, I am happy to fix it asap.

        Show
        Christian Schlichtherle added a comment - - edited Sorry for the late answer but I have been very busy. I tried the following program to reproduce this issue: package com.company.mavenproject3; import de.schlichtherle.truezip.file.*; import java.io.*; public class HelloWorld { public static void main( final String [] args) throws IOException { final Writer writer = new TFileWriter( new TFile( "dummy.war/foo.zip/realAchive.zip/HälloWörld.txt" )); try { writer.write( "Hello world!\n" ); } finally { writer.close(); } } } Note that I've created dummy.war and foo.zip as regular directories before running the program. I then run the program many times using JDK 1.7.0.11 and JDK 1.6.0.37 on Mac OS X 10.8.2. The result was that I cannot reproduce this issue. When I debug-step through the programm I can see that the temp file gets created upon the constructor call and unmounted in the application shutdown hook (which calls TVFS.umount()). So everything looks fine. I do get reports about file system errors occasionally. However, they are all from Linux and were not reproducible. TrueZIP has comprehensive multithreaded integration tests which pass with flying colors on Windows and Mac OS X, so I am led to believe that this may be an issue with the Linux port of the JDK, the OS, its file system implementation or a weird combination of all three. If you can provide me with a reproducible issue, I am happy to fix it asap.
        Hide
        Christian Schlichtherle added a comment -

        I just realized you never said you are using Linux. Let's see.

        Show
        Christian Schlichtherle added a comment - I just realized you never said you are using Linux. Let's see.

          People

          • Assignee:
            Christian Schlichtherle
            Reporter:
            jvanerp
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: