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!
- 1219 megtekintés
Hozzászólások
Neked is ajanlom a [code] taget, jobb, mint a <code>.
--
|8]
- A hozzászóláshoz be kell jelentkezni
Ahh, tisztább, szárazabb érzés... :)
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
Ez egy vastag kliens megoldás, jellemzően windows-okon megy.
Ráadásul egy másik app hívja a java modult, ami elvégzi az adott feladatot (megjelenít egy fájlt pl.). Sajnos erre nincs kerülő út, mivel a program kilép, miután megcsinálta amit meg kell.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Igen, így van. Nem, nem lehet átalakítani. A fő kliens ostoba, mint a kő. Csak command line-ból tudom a java app-omat hívni. Pl. socket-en keresztül sem tudom megszólítani :(.
- A hozzászóláshoz be kell jelentkezni
É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.
- A hozzászóláshoz be kell jelentkezni
Hát nem. Egy ilyen s***r apróság miatt meg főleg nem.
De ez a fájlban üzengetős még jutott eszembe :),
- A hozzászóláshoz be kell jelentkezni