File lock probléma

Fórumok

Hello,

Adott az alábbi cucc. Egy blob-ot vadász elő, majd meghívja a hozzá társított app-ot (pl. pdf esetén acrobat reader stb.).
Ha mondjuk egy nagyobb zip fájlt szedek elő, akkor az a helyzet, hogy a proc.waitfor() okosan megvárja, míg a windows explorer elindul, de már nem várja meg, míg a fájlt felolvassa. A következő sorom, pedig a file.delete(), ami törli az input állományt, mivel ez itt egy fapados megtekintés funkció (eg. user nem módosíthat az állományban semmit.)
Szóval erre kellene valami működő megoldás.


public void View_File(String outfile) throws Exception {

        String rundll = "cmd /c ";
        String param=null;
        File file = new File(outfile);
        FileChannel channel =  new RandomAccessFile(file, "r").getChannel();
        FileLock lock=null ;

try {
            Gen_Log(hdm.DocId,hdm.Fver,"I",hdm.message.getProperty("msg5"),hdm.DocAzon);
            //file.setReadOnly();
            Gen_Log(hdm.DocId,hdm.Fver,"I",rundll + " ' " + outfile+" ' ",hdm.DocAzon);
            param="\""+ outfile+"\"";
            hdm.log.info(rundll +  param);
            Process proc = Runtime.getRuntime().exec(rundll+param);
            proc.waitFor();

            try {
                lock = channel.tryLock();
            } catch (NonWritableChannelException e) {
                hdm.log.info("file lock");
            }
            lock.release();
            channel.close();
            
            //file.delete();
        } catch (IOException ex) {
            if(file.exists()) {
               file.delete();
            }
            throw ex;
  }

}

Próbálkoztam, hogy megnézem van e még lock a fájlon (explorer fogva tartja e még:), de meddig várjak itt ? Amíg tudok lockot szerezni ?
Köszönöm!

Hozzászólások

Neked is ajanlom a [code] taget, jobb, mint a <code>.

--
|8]

Ha jól értem: Létrehozol egy ideiglenes fájlt, és elindítasz egy hozzá passzoló programot. Ezután meg akarod várni, hogy a program "felolvassa" a bemenetet, és a lehető leghamarabb törölni akarod az ideiglenes fájlt.

Na, általában ez a lehető leghamarabb akkor van, amikor a fájl nézegetését befejezték, addig ugyanis lehetséges, hogy a nézegető nyitva tartja a fájlt. UNIX-on lehetne törölni hamarabb (a nézegetés közben) is, de Windowson nem. Például, ha a bemenet egy mp3 fájl, a "nézegető" pedig egy lejátszó, akkor nyitva lesz a fájl elég sokáig.

--
CCC3

Pontosan. Működik is minden esetben, kivéve, ha tömörített állományról van szó. A proc.waitfor() megvárja, míg a hívott program befejeződik, de ebben az esetben a hívott program (gondolom explorer.exe) meghívja a tömöríŧett fájl nézegetőt, amiről az én programom már nem tud semmit.
Visszatér a hívás, törli a fájlt miközben a nézegető még bőszen olvasná fel.

Aha, én csak arra gondoltam, hogy az ilyen lockolható/nem lockolható, törölhető/nem törölhető dolog rendszerfüggő, nem szabad rá alapozni. Az a jó megoldás, ha a program megjegyzi, hogy milyen fájlokat csinált, és később, amikor már biztosan nem kellenek (pl. kilépéskor) letörli őket. Új programindításkor pedig meg lehet nézni, nem maradt-e letörletlen munkafájl a korábbi sessionból. A /tmp-be meg ilyen helyekre szokták tenni az effélét. A lockolás nem jó.
--
CCC3

Szóval minden fájl megnyitáskor elindul egy java program, megnyitja a fájlt, aztán be is záródik? Nem lehetne ezt átalakítani úgy, hogy a java processből is csak egy fusson és annak üzengessen a fő kliens program? Akkor ráérne a leálláskor törölni a fájlokat ráadásul valószínűleg gyorsabb is lenne.

Én már gányoltam ilyet. Barátom a wget. El kell indítani a java process-t (mondjuk embeddelt http szerverrel) valahogy az elején és a kő buta kliensből wget-tel url-eket hívogatni. Nálam annyi különbség volt, hogy szerveren szervizként futott egy régi Delphi progi, az hívta a wget-et, amivel üzentem a tomcat-ben futó webalkalmazásnak. De akár fájlon keresztül is üzenhetsz (akkor nem kell socket). Ebben az esetben a fő kliensnek fájlba kell írni, azt is össze lehet hozni akár egy bat-ban is. A java processz meg azt figyeli.
Persze gondolom nem ilyen nagy átalakítást szeretnél.