[JAVA] Permessi di accesso a file in Vista

[franksisca]

allora...ho finito la mia bella applicazione che lavora con i file, ma qualndo al eseguo (post offuscamento) su XP tutto bene, su Vista NO, ovvero non mi salva i file.

credo(suppongo, visto che non ho sorgenti e non posso verificare) che sia un problema di accesso ai file.

se è così qualcuno può suggerirmi su come risolverlo?
grazieeeee


P.S.: è possibile cambiare icona al mio jar??? (intendo l'icona che appare sul desk non quella in altro a sinistra )

[fero86]

"hai finito la tua bella applicazione" e "non ne hai i sorgenti per verificare"?

comunque, nel caso si trattasse effettivamente di problemi di permessi su file, queste sono le domande cruciali:
1) devi distribuire la tua applicazione? se no basta che cambi i permessi sul tuo PC.
2) per quale motivo stai cercando di scrivere in cartelle dove non puoi scrivere? i permessi dei files e delle directories su Vista non é che siano impostati a culo.

[franksisca]

Originariamente inviato da fero86

"hai finito la tua bella applicazione" e "non ne hai i sorgenti per verificare"?

si...semplicemente perchè ho i sorgenti a cosenza e ora sono a rossano (fino a domani)

quindi la domanda è per mettere le mani avanti, così domani arrivo e sò cosa cercare

Originariamente inviato da fero86

1) devi distribuire la tua applicazione? se no basta che cambi i permessi sul tuo PC.

si ovvio altrimenti non avrei chiesto

Originariamente inviato da fero86

2) per quale motivo stai cercando di scrivere in cartelle dove non puoi scrivere? i permessi dei files e delle directories su Vista non é che siano impostati a culo.

cerco di scrivere in file che ho creato io:

con un installer io creo la struttura ad albero del mio programma, e poi all'interno di queste cartelle faccio delle operazioni.
una delle operazioni è "scrivere sul file".
quindi le cartelle non sono quelle di sistema (non voglio distruggere niente X_X) ma sono delle sottocartelle "mie".

ora che ci penso però...posso avviare il programma da console e vedere se genera qualche errore.

a volte mi perdo in un bicchiere mezzopieno d'acqua

[fero86]

Originariamente inviato da franksisca

si...semplicemente perchè ho i sorgenti a cosenza e ora sono a rossano (fino a domani)

usa Live Mesh

cerco di scrivere in file che ho creato io:

con un installer io creo la struttura ad albero del mio programma, e poi all'interno di queste cartelle faccio delle operazioni.
una delle operazioni è "scrivere sul file".
quindi le cartelle non sono quelle di sistema (non voglio distruggere niente X_X) ma sono delle sottocartelle "mie".

cosa in linea di principio sbagliatissima: queste porcate si fanno su Linux, su Windows per motivi di sicurezza le cartelle %APPDATA% stanno da tutt'altra parte rispetto alle cartelle di installazione dei programmi in Program Files e hanno anche una configurazione di sicurezza del tutto diversa; il fatto che Java non ti permetta di sapere dove si trova la cartella %APPDATA% é ovviamente uno dei motivi per cui Java sucks.

comunque solitamente la soluzione a questo fastidiosissimo problema di Java consiste semplicemente nell'installare il programma in una cartella su cui hai pieno accesso, per esempio una sottocartella dei documenti.

[franksisca]

Originariamente inviato da fero86

usa Live Mesh

non sò cosa sia O_O

Originariamente inviato da fero86

cosa in linea di principio sbagliatissima: queste porcate si fanno su Linux, su Windows per motivi di sicurezza le cartelle %APPDATA% stanno da tutt'altra parte rispetto alle cartelle di installazione dei programmi in Program Files e hanno anche una configurazione di sicurezza del tutto diversa; il fatto che Java non ti permetta di sapere dove si trova la cartella %APPDATA% é ovviamente uno dei motivi per cui Java sucks.

comunque solitamente la soluzione a questo fastidiosissimo problema di Java consiste semplicemente nell'installare il programma in una cartella su cui hai pieno accesso, per esempio una sottocartella dei documenti.

ok, proverò a salvarlo su Documenti

[franksisca]

allora, sono qui per "cercare" la soluzione (per vista per il momento...poi mi installo seven e vediamo).


il problema è questo:

java.io.FileNotFoundException: data\cliente.ktm (Accesso negato)
       at java.io.FileOutputStream.open(Native Method)
       at java.io.FileOutputStream.<init>(Unknown Source)
       at java.io.FileOutputStream.<init>(Unknown Source)
       at saving.ArchivioClienti.salvaClienti(Unknown Source)
       at saving.ArchivioClienti.caricaClienti(Unknown Source)
       at graphic.I.actionPerformed(Unknown Source)
       at javax.swing.AbstractButton.fireActionPerformed(Unknown Source)
       at javax.swing.AbstractButton$Handler.actionPerformed(Unknown Source)
       at javax.swing.DefaultButtonModel.fireActionPerformed(Unknown Source)
       at javax.swing.DefaultButtonModel.setPressed(Unknown Source)
       at javax.swing.AbstractButton.doClick(Unknown Source)
       at javax.swing.plaf.basic.BasicMenuItemUI.doClick(Unknown Source)
       at javax.swing.plaf.basic.BasicMenuItemUI$Handler.mouseReleased(Unknown
Source)
       at java.awt.Component.processMouseEvent(Unknown Source)
       at javax.swing.JComponent.processMouseEvent(Unknown Source)
       at java.awt.Component.processEvent(Unknown Source)
       at java.awt.Container.processEvent(Unknown Source)
       at java.awt.Component.dispatchEventImpl(Unknown Source)
       at java.awt.Container.dispatchEventImpl(Unknown Source)
       at java.awt.Component.dispatchEvent(Unknown Source)
       at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source)
       at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source)
       at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)
       at java.awt.Container.dispatchEventImpl(Unknown Source)
       at java.awt.Window.dispatchEventImpl(Unknown Source)
       at java.awt.Component.dispatchEvent(Unknown Source)
       at java.awt.EventQueue.dispatchEvent(Unknown Source)
       at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
       at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
       at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
       at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
       at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
       at java.awt.EventDispatchThread.run(Unknown Source)

come supponevo il problema è di accesso ai file.
la mia domanda è....basta che quei file che utilizzo li salvo in "C:\dcocumenti\programmamio\miofile" oppure c'è qualche soluzione più elegeante?

[RaouL_BennetH]

Domandina scema

Se hai creato un installer, su Vista, non è che ti basterebbe lanciarlo con esegui come amministratore ?!?

[franksisca]

Originariamente inviato da RaouL_BennetH

Domandina scema

Se hai creato un installer, su Vista, non è che ti basterebbe lanciarlo con esegui come amministratore ?!?

boh...non ci capisco niente...e non ho un pc conqvista qui...quindi quando lo provo su vista non ho il sorgente..e quando ho il sorgente non ho vista -.-

[franksisca]

ho aperto un thread ma avevo scordato di avere questo.


comunqu sono stesso problema

[PGI-Bis]

Originariamente inviato da fero86

il fatto che Java non ti permetta di sapere dove si trova la cartella %APPDATA% é ovviamente uno dei motivi per cui Java sucks.

Per uno che sa usare Java trovare la cartella APPDATA è difficile quanto tagliarsi le unghie.

[franksisca]

Originariamente inviato da PGI-Bis

Per uno che sa usare Java trovare la cartella APPDATA è difficile quanto tagliarsi le unghie.

ora dimmi quanto ridi se ti dico che ho le unghie dei piedi incarniti per problemi avvenuti al taglio???

[PGI-Bis]

Due parole: metodo nativo.

[franksisca]

Originariamente inviato da PGI-Bis

Due parole: metodo nativo.

ok, mai usati.

cerco su google qualcosa al riguardo, se nel frattempo puoi indirizzarmi tu...

[PGI-Bis]

Premetto che non conosco nulla delle API di windows e il fatto che io sia riuscito ad ottenere il percorso di APPDIR in 5 minuti netti da una misura della difficoltà del problema.

Uno va a guardare come si fa ad ottenere la cartella APPDIR nelle API di Windows e, stando a google, risultano quattro linee di codice C/C++:

ITEMIDLIST* list;
char appdir[500];
SHGetSpecialFolderLocation(NULL, CSIDL_APPDATA, &list);
SHGetPathFromIDList(list, appdir);

A questo punto appdir contiene la cartella APPDATA.

Ora, Java ha questo straordinario e apparentemente ignoto pezzo di sè chiamato JNI. Diciamo che vogliamo copiare appdir in uno StringBuilder. Giusto per vedere. Bene, supponendo che questo StringBuilder sia creato in Java ci troviamo con;

jobject stringBuilder; //lo StringBuilder: tutti i reference JNI sono jobject salvo un paio

Diciamo che vogliamo riempire lo stringBuilder un carattere alla volta. StringBuilder ha il metodo append(char). Usiamo questo. Prima prendiamo il metodo:

jclass stringBuilderClass = env->FindClass("java/lang/StringBuilder");
jmethodID appendChar = env->GetMethodID(stringBuilderClass, "append", "(C)Ljava/lang/StringBuilder;");

poi lo invochiamo. Vogliamo dire "per ogni carattere in appdir finchè ce ne sono stringBuilder.append(c)?". Scriviamo:

for(int i = 0; (i < 500) & (appdir[i] != '\0'); i++) {
    env->CallVoidMethod(stringBuilder, appendChar, appdir[i]);
}

"env" è un puntatore JNIEnv che ottieni automaticamente da JNI quando realizzi un metodo nativo.

Questo tanto per dare un'idea dell'invocazione di metodi e di come appaiono gli oggetti JNI.

Passiamo al nostro problema.

Voglio ottenere la cartella "APPDATA".

1. Creo una classe Java con un metodo nativo (i nomi sono arbitrari):

package it.tukano.winapi;

public class WinApi {

	public native String getAppDir();
}

Compilo:

javac -d . *.java

Poi creo l'header JNI:

javah it.tukano.winapi.WinApi

L'header contiene il prototipo della funzione JNI che rappresenta la controparte nativa di getAppDir, cioè la funzione che sarà invocata ogni volta che io dirò:

winApi.getAppDir();

Il prototipo è un po' strano a vedersi ma è al 99% convenzionale. L'unica cosa da notare è che il metodo nativo getAppDir() è senza argomenti e restituisce uno String, la controparte nativa restituisce un jstring e ha due argomenti. JNIEnv è il puntatore alle funzioni globali di JNI, jobject è un riferimento al "this" dell'invocazione Java.

Comunque la definizione di quella funzione è brevissima:

//file dllmain.cpp
#include "it_tukano_winapi_WinApi.h"
#include <shlobj.h>

JNIEXPORT jstring JNICALL Java_it_tukano_winapi_WinApi_getAppDir
  (JNIEnv *env, jobject obj)
{
	int SIZE = 500;
	char buffer[SIZE];
	ITEMIDLIST* list;
	SHGetSpecialFolderLocation(NULL, CSIDL_APPDATA, &list);
	SHGetPathFromIDList(list, buffer);
	return env->NewStringUTF(buffer);
}

NewStringUTF è una funzione JNI che dato un buffer di char restituisce una nuova stringa java (che in JNI è un jstring).

Compilando con il tuo ide c++ottieni la tua dll. Per usare il tuo WinApi dirai:

public class Main {

	public static void main(String[] args) {
		System.loadLibrary("winapi");
		it.tukano.winapi.WinApi winApi = new it.tukano.winapi.WinApi();
		System.out.println(winApi.getAppDir());
	}
}

Sono 28 linee di codice, prova inclusa.

[franksisca]

asd....grazie mille.


provo e vi faccio sapere

[fero86]

Originariamente inviato da PGI-Bis

Due parole: metodo nativo.

c'é sempre il dubbio che un'intera DLL sia overkilling per chiamare una sola API; la possibilitá che esiste in C# di invocare direttamente l'API ad esempio toglierebbe l'imbarazzo.

tra l'altro un programmatore che sappia usare Java raramente sa usare anche il C++ e men che mai le API Win32, di conseguenza il problema non é cosi semplice come tagliarsi le unghie, specialmente se per risolverlo ricorre a chissá quali minchiate trovate su Google; il tuo codice ad esempio é semi-delirante, avresti dovuto scrivere una cosa del genere:

CHAR szBuffer[MAX_PATH];
HRESULT hr = SHGetFolderPathA(NULL, CSIDL_APPDATA, NULL, SHGFP_TYPE_CURRENT, szBuffer);
if (FAILED(hr) || (hr == S_FALSE))
{
    // gestire l'errore
}

[PGI-Bis]

Ho incollato la prima cosa che ho trovato, premettendo a bella posta che non conosco le API di windows. Se io dovessi fare qualcosa di specifico per Windows probabilmente mi prenderei un bel libro e me lo leggerei. Ma google va benissimo: in effetti verificando su MSDN si sarebbe scoperto che la funzione che ho trovato io è stata sostituita da SHGetFolderLocation.

Io sono dell'idea che un programmatore per il fatto di essere tale debba essere in grado di usare C++ esattamente quanto è in grado di usare Java o un qualsiasi altro linguaggio.

Altrimenti resti lì in mutande ogni volta che non trovi una funzione nelle api standard, il che è francamente inaccettabile.

Una libreria dinamica per una funzione non è più eccessivo che cambiare interamente piattaforma per quell'unica funzione. Specialmente se l'alternativa è C#.

[franksisca]

allora, ho fatot le seguenti cose:

1) scaricato devc++
2) creato il file java

package it.tucano.winapi;


public class WinApi {

	public native String getAppDir();
}

3) generato tramite javah il file it_tucano_winapi_WinApi.h
4) aperto devc++ e creato un nuovo progetto ddl
5) nuovo file cpp chiamato dllmain.cpp
6) copiato il codice di pgi

//file dllmain.cpp

#include "it_tucano_winapi_WinApi.h"
#include <shlobj.h>

JNIEXPORT jstring JNICALL Java_it_tucano_winapi_WinApi_getAppDir
  (JNIEnv *env, jobject obj)
{
	int SIZE = 500;
	char buffer[SIZE];
	ITEMIDLIST* list;
	SHGetSpecialFolderLocation(NULL, CSIDL_APPDATA, &list);
	SHGetPathFromIDList(list, buffer);
	return env->NewStringUTF(buffer);
}

(provo questo "per ora" e poi quello di fero86)
7) compilo con dev e mi dà questo errore:

Compilatore: Default compiler
Building Makefile: "C:\Dev-Cpp\Makefile.win"
Esecuzione di make...
make.exe -f "C:\Dev-Cpp\Makefile.win" all
g++.exe -c dllmain.cpp -o dllmain.o -I"C:/Dev-Cpp/lib/gcc/mingw32/3.4.2/include" -I"C:/Dev-Cpp/include/c++/3.4.2/backward" -I"C:/Dev-Cpp/include/c++/3.4.2/mingw32" -I"C:/Dev-Cpp/include/c++/3.4.2" -I"C:/Dev-Cpp/include" -DBUILDING_DLL=1

In file included from dllmain.cpp:3:
it_tucano_winapi_WinApi.h:2:17: jni.h: No such file or directory
In file included from dllmain.cpp:3:
it_tucano_winapi_WinApi.h:15: error: `JNIEXPORT' does not name a type

dllmain.cpp:6: error: `JNIEXPORT' does not name a type

make.exe: *** [dllmain.o] Error 1

Esecuzione terminata

se ho capito bene il file generato da me (it_tucano_winapi_WinApi.h) non si collega alla libreria jni.h

la mia domanda è: dove trovo questa libreria?

[franksisca]

questa parte risolta così

Pima di compilare la nostra libreria occorre impostare i parametri del compilatore perchè trovi "jni.h".
L'header "jni" si trova nel jdk, cartella "include". Con dev-cpp la cosa si risolve così:

menu "strumenti"->"opzioni di compilazione". Nella finestra che compare seleziona la scheda "cartelle" quindi la scheda

"include C". Sopra il bottone "cancella invalida" c'è un pulsante che permette di selezionare una cartella del sistema.

Premilo e trova la cartella "c:\j2sdk1.4.2\include". Selezionala e poi premi "aggiungi". Fai lo stesso con la cartella

"c:\j2sdk1.4.2\include\win32". La posizione della cartella può cambiare a seconda dell'installazione del JDK presente sul tuo sistema operativo.

A questo punto non resta che lasciar compilare la libreria a Dev-cpp.

continuo e vi aggiorno

[fero86]

Originariamente inviato da PGI-Bis

Ho incollato la prima cosa che ho trovato, premettendo a bella posta che non conosco le API di windows. Se io dovessi fare qualcosa di specifico per Windows probabilmente mi prenderei un bel libro e me lo leggerei. Ma google va benissimo: in effetti verificando su MSDN si sarebbe scoperto che la funzione che ho trovato io è stata sostituita da SHGetFolderLocation.

non serve urlare la tua ignoranza, é sufficiente non palesarla in principio. non era quello l'unico motivo di semi-delirio nel codice che hai riportato: hai usato male le stringhe, infatti hai passato un vettore di char ad un parametro di tipo LPTSTR e le due cose sono equivalenti solo se non definisci la macro UNICODE prima di includere windows.h, che peró nelle versioni recenti di Visual C++ viene definita di default in molti templates di progetti tramite opzione al compilatore.
inoltre, essendo tu un programmatore Java e non C++, non sei abituato all'idea di dover liberare le risorse che allochi e quindi non hai chiamato la CoTaskMemFree per liberare il puntatore restituito da SHGetSpecialFolderLocation (si, un leak bravissimo!).

ripeto che per un programmatore che sa usare Java non é necessariamente* una questione di pochi secondi evitare di creare la solita applicazione ottusa che mette i dati nel suo stesso ramo di directories e quindi non é compatibile con Vista e futuri, mentre invece lo sarebbe se Java offrisse un modo semplice per conoscere i well-known path del sistema senza scendere a livello nativo.

* "non necessariamente" nel senso che esistono anche programmatori contemporaneamente esperti in Java e C++, e questi invece si spera che siano in grado.

Io sono dell'idea che un programmatore per il fatto di essere tale debba essere in grado di usare C++ esattamente quanto è in grado di usare Java o un qualsiasi altro linguaggio.

l'onniscienza non esiste; tant'é che io non sono nemmeno sicuro di aver scritto bene "onniscienza".

Una libreria dinamica per una funzione non è più eccessivo che cambiare interamente piattaforma per quell'unica funzione.

un conto é cambiare piattaforma e ricominciare da zero un progetto ormai al 99% e un conto é scegliere la piattaforma giusta per quel progetto fin dall'inizio. la migliore integrazione di .NET con Windows mi sembra un'ottima ragione per evitare Java se sai che il tuo programma girerá solo su Windows (altrimenti detto: non scriverei mai in Java un programma che deve girare solo su Windows).
io non é che posso mettermi a scrivere una DLL JNI tutte le volte che devo fare un programma Java che deve girare anche su Windows (perché poi come la mettiamo quando il programma deve girare non solo su Windows? non prendiamoci in giro, la libreria nativa per un compito cosi idiota é un giro della Madonna, anche come curva d'apprendimento non c'é paragone con un'alternativa piu semplice come un metodo o una property che restituiscono il path richiesto).

Specialmente se l'alternativa è C#.

spiritoso, hai voglia di darmi un'altra volta ragione per sfinimento?