Newsgroup: it.comp.lang.visual-basic
Titolo: cartella franca

Il mio programma in fase d'installazione copia tutti i file da modificare
dentro la cartella 
C:\Documents and Settings\All Users\Dati applicazioni\....
sembra che l'utente USER del sistema operativo non abbia diritto di
scrittura in codesta cartella ...
allora mi spiegate dove devo andare a mettere i miei file comuni ?
esiste una cartella franca dove anche l'utente più sfigato può andare a
scrivere ? cosa dice lo standard Microsoft ?
grazie di cuore per qualsiasi vostra utile risposta
Alessandro
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 Alessandro
guardavo adesso la dati applicazioni di all users e la mia. c'e' roba p.e.
di acrobat in tutt'e due.
mi sa che in all users metti quello che devono leggere, in quella di ogni
utente quello che ciascuno deve scrivere.
controlla i permessi. ho scoperto che quando installo le macchine (win 2000)
se metto dei collegamenti sul desk di all users, oltre a non poterli
cancellare (e' quello che voglio), non possono neanche eseguirli se prima
non li ho eseguiti io come admin *da li'*. na palla...
ciao, j.

io vorrei sapere come posso far lavorare i miei utenti USER con la mia
applicazione, esisterà una cartella comune dove appunto anche il più
infimo degli utenti ha i diritti di scrittura 


 infimo degli utenti ha i diritti di scrittura
Non sono molto esperto ma:
1) Entri come Admin e definisci una cartella con i permessi a tutti
2) Provi a lavorare con %temp%, non so in VB come richiamarlo ma se fai
start/esegui %temp% ti va nella cartella temporanea automaticamente. In
questo modo però non hai i file in comune fra gli utenti.
Se trovi un'altro modo, potrebbe far comodo pure a me :)

 infimo degli utenti ha i diritti di scrittura
Per ogni utente esiste una cartella definita in Environ("TEMP") o 
Environ("TMP"), dove l'utente può scrivere i suoi file temporanei.
E' evidente, però, che questa cartella non è la stessa per ogni utente.
In generale, non esiste nel mondo NTFS una cartella scrivibile da tutti gli 
utenti.
Cioè, di default tutto il disco è scrivibile, ma è prassi abbastanza comune 
impostare delle restrizioni NTFS agli utenti di basso livello.
Ciao
Alberto
-- 
E tutto mi sembrava andasse bene... 

uno dei miei primi problemi è la scrittura su un file ini che il mio
programma a volte esegue (soprattutto all'avvio), se nel sistema operativo
mi entra l'utente USER ecco che salta tutto.
pensavo che la cartella 
C:\Documents and Settings\All Users\Dati applicazioni
fosse una zona franca invece così non è


 
Questa e' la cartella dove l'amministratore (o i programmi installati 
come amministratore) mette cio' che deve essere visibile a tutti gli utenti.
Se ad esempio vuoi mettere un'icona di un programma sul desktop di tutti 
gli utenti basta mettere il link in:
C:\Documents and Settings\All Users\Desktop
Per risolvere il tuo problema puoi procedere cosi':
- l'installazione la fa un amministratore
- i file comuni vengono messi in d&S\all Users\... in modo che siano 
visibili a tutti gli utenti.
Se un utente deve memorizzare delle impostazioni personalizzate le salvi 
in d&s\nomeutente\...
ciao
	maxx
-- 
NOSPAM: Rimuovere i trattini dallo username!
Cut hyphens from my username!

 in d&s\nomeutente\...
e' esattamente quello che gli ho detto io :)

Il 04/03/2005 13.38, javalab scrisse:

Hai ragione, ho saltato prorprio quella frase, sai le tecniche di 
lettura veloce...
Non ti sarai offeso?! :-)


 impostare delle restrizioni NTFS agli utenti di basso livello.
...cioè dipende da NTFS?
Senti questa: macchina WinXP in rete, un mio programma deve utilizzare un
file .mdb in certo path locale.
Mi loggo come amministratore, creo una cartella in C:, dentro ci copio il
file .mdb, avvio il mio programma e gli passo il path
C:\miacartella\file.mdb, lui lo apre, lo legge, lo stampa. Ma quando io
aggiungo un record, XP mi dice che la cartella è di sola lettura!!
Apro la cartella a mano, cerco di rinominare l'.mdb, XP mi dice "...cartella
di sola lettura..."!!
Cerco di rinominare la cartella, XP dice "...sola lettura..."!!
Clic destro, Proprietà, casella Sola lettura è grigia. Tolgo il segno di
spunta, OK, ri-clic destro, ancora Proprietà: la casella è di nuovo grigia!!
Due mesi di Google non mi hanno fatto trovare la soluzione. Il responsabile
IT mi ha detto che se gli risolvo qs. problema mi offre la pizza. Più che la
soluzione - in una pagina MSDN si vaneggiava del registry - vorrei capire:
come si permette XP?!? La cartella è mia, l'ho creata io, e sono
amministratore. Perché sola lettura?
Potete provare: create una cartella dovunque, cliccate col destro e
scegliete Proprietà, modificate l'attributo Sola lettura, confermate,
provate a riaprire Proprietà e vedete se ha mantenuto l'impostazione.
A chi mi chiede: "perché ti ostini ancora con VB6?" io rispondo "perché
voglio continuare a usare 98"...
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

 "perché voglio continuare a usare 98"...
Per carità...


 ha scritto

il problema non e' vb6, che anche in una rete seria gira benone, magari con
qualche escamotage sui permessi che ha l'utente e eche ha il programma. il
prob e' win9: in situazioni aziendali private o pubbliche ormai e'
impossibile, se la macchina e' connessa o puo' connettersi alla / a una
rete. i win9 non garantiscono l'autenticazione e la protezione di documenti
posta ecc personali. le ultime leggi hanno fatto un gran bel WindowsUpgrade
:)
cmq, stai dicendo che se sulla macchina xp tu
entri come admin
cartella > propr
condivisione -> everyone
protezione -> rimuovi tutti i permessi esistenti (per farlo devi rimuovere
anche la spunta "eredita"), metti te stesso con controllo completo, e gli
utenti che ti pare con tutto quello che ti pare salvo controllo completo
non ti lascia scrivere nella cartella ?
niente di grave: ho litigato a lungo con 2003 server.
creavo una cartella sul server
in locale come admin (=io, e lo sa benissimo :) ok.
da remoto come io dal portatile non mi ci lasciava scrivere.
entravano in conflitto condivisione e protezione.
il 2003 nei permessi ha altre finezze
lettura: [_]consenti [_]nega
scrittura: [_]consenti [_]nega
a me sembrava ovvio che se uno non consente, nega. non ho ancora capito cosa
succede se li lascio tutti e due bianchi o tutti e due spuntati. non mi
sembra comunque una bella pensata.
ciao, j.

 spunta, OK, ri-clic destro, ancora Proprietà: la casella è di nuovo grigia!!
Trattandosi di un mdb...
Risolvi se imposti i permessi rw *in cascata* cioe` per tutti
gli oggetti che sono (e saranno) in quella cartella?
Sto pensando al file .ldb che access si crea.
-- 
ciao, hal

 Sto pensando al file .ldb che access si crea.
No, non risolvo. Nemmeno se creo una cartella vuota mi lascia togliere il
segno Sola lettura della cartella.
Mi sono accorto del problema perchè un database di Access modificava un file
di testo, e tutto funzionava a modino in varie macchine. Ha smesso di
funzionare quando è stato messo su una macchina XP, e indagando mi sono
accorto di questa faccenda. Non ho ancora trovato una soluzione funzionante,
ma ho trovato un sacco di gente che ci si è scornata, cosa che mi rincuora
un po' perché pensavo di essere impazzito io (il che, comunque, non è ancora
escluso...)
Per javalab: già, belline le due caselline. Io ora lavoro con il 98se, ma
appena posso controllo anche il discorso condivisione/protezione/eredita.
Ma, andando a memoria, se il computer non è in rete, la scheda condivisione
non dovrebbe essere visibile, o sbaglio? Roba da it.comp.winxp....
La cosa che mi stravolge è: c'è un problema che riguarda la creazione delle
cartelle. Come può essere ignorato, cioè non considerato un problema
critico? Come può non esserci una patch definitiva? Creare le cartelle è una
delle sette operazioni fondamentali di ogni sistema operativo, come si può
convivere con questa limitazione? Se solo io e poche centinaia di altri ce
l'abbiamo, perché nessuno ci dice "Guarda, il problema è noto da tempo, la
patch è a qs. indirizzo...", o al limite "...ci stiamo ancora lavorando...",
come per ogni problema critico? E se invece è un comportamento standard di
XP, come mai nessuno ha ancora chiesto i danni alla M$oft? Per me è come se
uno comprasse una macchina, e si accorgesse che in salita può curvare solo a
sinistra. Io creo, sposto e distruggo cartelle tutti i giorni: se un s.o.
non mi permette di farlo passo subito a Linux. O no?


 non mi permette di farlo passo subito a Linux. O no?
Soprattutto in linux devi considerare i permessi, molto piu` che
in windows. La differenza sta nel fatto che in ambiente *n*x sei
gia` abituato / orientato a considerare  zone del  disco dove l'
utente puo` scrivere ed altre no. La vera differenza e` che IMHO
chmod e` *molto* piu` facile da usare delle millemila finestre e
click che richiede windows.
-- 
ciao, hal

 click che richiede windows.
quando maneggiavo un pochino unix e xenix anni fa, sembrava anche a me, per
quanto in nt4 i permessi li dai e togli in 10". ma la finestrina completa di
2003 l'hai vista (seno' te la mando) ? a parte il delirio del "permetti AND
nega" o "non permettere AND non negare", a tutte quelle definizioni di
permessi ci arrivi *altrettanto facilmente*, e in carattere anziche' in
grafica, con chmod ? hmmm....
ciao, j.

 grafica, con chmod ? hmmm....
be', non sono un guru di unix, quindi non conosco usi
sofisticati di chmod: finora ho sempre risolto i casi
complicati tramite creazioni di gruppi (che penso sia
strada maestra anche per NT e famiglia).
-- 
ciao, hal

 strada maestra anche per NT e famiglia).
direi di si'. stranamente io che sono legato alle classi li' ho capito
subito come funzionava. si vede che il potere logora chi non e' admin :)

 click che richiede windows.
cacls
Un Paperino in vena D'Itrica.

 Un Paperino in vena D'Itrica.
:-)
-- 
ciao, hal

 Un Paperino in vena D'Itrica.
Urghhh!!! No, ti prego... guarisci finché sei in tempo...
:-P
Ciao.
-- 
BSD is for UNIX lovers -- linux is for Windows haters.

 delle millemila finestre e click che richiede windows.
Potrebbe essere vero, tieni presente perň che il sistema di gestione dei
permessi di unix č estremamente piů semplice e limitato e molto meno
flessibile di quello di Windows. 
Ovviamente non considerando l'uso delle ACL sotto Unix perché chmod non 
servirebbe a molto...


 facilmente*, e in carattere anziche' in grafica, con chmod ? hmmm....
No, perché è lo stesso sistema dei permessi Unix a non permettertelo.


 No, perché è lo stesso sistema dei permessi Unix a non permettertelo.
appunto. per quanto ricordo, chmod ha 3 serie di 3 caratteri.
utile o inutile che sia, per windows, specie l'ultimo, hanno pensato ben
oltre.
ciao, j.

 :-P
Poi mi passa, non ti preoccupare. Di mio tendo ad essere piuttosto
logorroico :-).
Bye, G.

 oltre.
Decisamente. Comunque c'è da dire che il sistema delle ACL (come in Win) è 
ormai implementato da tempo anche in Unix.


 i piu' restrittivi. una volta capita, piu' o meno ora ce la cavo.
...non è che il tuo sistemista sa anche come si aggira la mia situazione?...
Ciao a tutti, vado in gita.
