Newsgroup: it.comp.macintosh
Titolo: Disinstallazione.. e le preferenze ?? rimangono li' ??

Nelle istruzioni di disinstallazione di Thunderbird dice semplicemente 
di trascinare il file nel cestino.
Pero' le preferenze che fanno ?? Rimangono li' ??
E.

 wrote:

si'. Ma a differenza del pc, sai quali sono e dove sono. Ci metti un
attimo a cancellarle.
-- 
TacaLit

 attimo a cancellarle.
E se ce le lasci non ti insozzano il sistema. Poi di solito sono file di
testo di pochi kb.
-- 
Popi, dall'iBook 14" G3@900 MHz
Per avere il mio vero indirizzo di posta, eliminate *BILL GATES*! :-)

EU6eN10 wrote:

si, ma:
1-sai dove sono
2-puoi riconoscerle e cancellarle senza problema
3-se anche le lasci sono dei semplici e piccoli file di testo che non 
danno fastidio e nessuno
puoi dire loi stesso di tutte le DLL di UinDOS?
;)
ciao ciao

 ciao ciao

 Pero' ora che so questa cosa, li rimuovero' manualmente.
io faccio mela-F dal finder (cerca), metto il nome del programma che
voglio disinstallare, e cancello tutto quello che trovo...
-- 
"i was high, but she was the sky"
use the condom. remove it to reply.

 Le puoi cancellare a mano, sono nella tua Libreria.
Ma che voi sappiate: esiste un tool che mi riporta i file che non
vengono aperti da + di 6 mesi, 1 anno o 2 anni?
Sarebbe un buonissimo spunto per eliminare preferenze non + utili.
Ciao
Tonsola

 Tonsola
Una ricerca "manuale" nella cartella non è cosa tragica...

 Una ricerca "manuale" nella cartella non è cosa tragica...
Da Panther significa aprire la cartella Libreria dell'utente e ordinare
per data di modifica e valutare la "vecchiezza" del file.
Reiterare l'operazione per ogni sottocartella diventa + complex....
Cmq il finder non è secondo me il massimo... panther a quanto ne so può
ordinare in base alle date di modifica... servirebbe qualcosa che
riporti i file che sono lì a tener spazio sull'HD senza mai essere
neanche letti.
Ciao
Tonsola

 wrote:

Da Terminal, 
    find . -type f -atime +95
elenca tutti i file (nel directory corrente o sottocartelle qualsiasi)
non acceduti in alcun modo da piu` di 95 giorni, ad esempio.  Ovviamente
puoi usare qualsiasi numero (180, 365, vedi tu) al posto di quel 95.
Come farlo *da GUI* non so, sicuramente qualche GUIomane non manchera`
di suggerire l'N+1-esimo shareware o freeware per fare l'N+1-esimo
compito che col Terminal che passa mamma Apple si fa gia` benissimo;-).
Alex

 "esattamente uguale", o posteriore, o ...) 
Scusa, ma *NON* e` la data di MODIFICA che il poster voleva, ma la data
di ULTIMO ACCESSO (lettura).  Infatti, nel comando find da terminale,
uso '-atime' (per Access-time), NON '-mtime' (per Modify-time).
Ripeto, quindi, che non so come farlo da GUI.  *NON* vedo una "data di
ultimo accesso" fra gli attributi "cercabili" dal Finder.
Alex
 

 abitualmente col sistema ci potra' illuminare.
Pronti:
kallisti:/tmp alex$ touch foo
kallisti:/tmp alex$ ls -lu foo
-rw-r--r--  1 alex  wheel  123 23 Jan 19:16 foo
kallisti:/tmp alex$ touch -a 01231715 foo
kallisti:/tmp alex$ ls -lu foo
-rw-r--r--  1 alex  wheel  123 23 Jan 17:15 foo
kallisti:/tmp alex$ 
Alex

 un'operazione di sola lettura non aggiorna la data.
Beh, _dovrebbe_ aggiornare la data di ultimo accesso.  In effetti, non
pare che lo faccia su Mac... su Linux:
[alex@lancelot tmp]$ touch -a -t 200501231715 foo
[alex@lancelot tmp]$ ls -lu foo
-rw-rw-r--    1 alex     alex            0 Jan 23 17:15 foo
[alex@lancelot tmp]$ cat foo
[alex@lancelot tmp]$ ls -lu foo
-rw-rw-r--    1 alex     alex            0 Jan 23 21:19 foo
[alex@lancelot tmp]$ 
...leggere un file aggiorna la "data di ultimo accesso", come da
standard Unix (Posix), mentre su Mac:
kallisti:/tmp alex$ touch -a -t 200501231715 foo
kallisti:/tmp alex$ ls -lu foo
-rw-r--r--  1 alex  wheel  5 23 Jan 17:15 foo
kallisti:/tmp alex$ cat foo
kallisti:/tmp alex$ ls -lu foo
-rw-r--r--  1 alex  wheel  5 23 Jan 17:15 foo
kallisti:/tmp alex$ 
...leggere un file non aggiorna la "data di ultimo accesso".
Puzza di bug del Mac, visto che evidentemente l'HFS l'atime lo registra
ma NON lo aggiorna al momento della lettura.  Peccato... se non altro
spiega perche` il Finder non permetta di accedervi -- per nascondere il
bug!!!
Quindi, per tornare alla domanda originale: DOVREBBE funzionare secondo
gli standard cui il Mac dice di aderire, ma NON funziona nella pratica,
ahime`, quindi si puo` considerare insolubile.
La prima *BUONA* ragione che abbia mai incontrato per spazzare via Mac
OS X e mettere al suo posto un altro Unix... sapere l'ultima data in cui
un file e` stato letto e` una feature veramente utile, e che per
misteriose ragioni il Mac FINGA di dirlo ma dica le bugie e` brutto!!!
Alex


che in effetti pare confermare che il bug e` noto per 10.3.7 -- ed e` un
RITARDO nell'aggiornamento di atime su disco.  Vabbe`... in effetti
bisognerebbe fare un poco di esperimenti; puo` darsi che il problema
originale (che riguardava verifiche di atime di mesi o anni) sia
comunque risolubile, dipende come gira 'sto ritardo...
Alex

 sera;
A me no...!  Ho appena controllato:
kallisti:/tmp alex$ ls -lu foo
-rw-r--r--  1 alex  wheel  5 23 Jan 17:15 foo
kallisti:/tmp alex$ ls -lu foo
-rw-r--r--  1 alex  wheel  5 23 Jan 21:21 foo
il primo ls -lu era quello che avevo fatto iersera (alle 21:21) che
mostrava che atime non veniva aggiornato.  Piu` tardi l'iBook e` andato
in sleep, ecc ecc, ma quella finestra di Terminal non l'avevo toccata, e
neppure il file.  Cosi` ho appena provato a dare il SECONDO ls -lu, e
noto che l'atime e` andato a posto.
Pero` non riesco a riprodurre facilmente l'osservazione di Joshua che
l'atime si aggiorna usando altre app per leggere.  Ad esempio:
kallisti:/tmp alex$ open -e foo
kallisti:/tmp alex$ ls -lu foo
-rw-r--r--  1 alex  wheel  5 23 Jan 21:21 foo
l'open ha aperto TextEdit, l'ho subito chiuso, e vedo l'atime ancora
"vecchio".  Allora ho aperto TextEdit da Finder, File->Recent, aprendo
ancora foo, chiuso subito, e:
kallisti:/tmp alex$ ls -lu foo
-rw-r--r--  1 alex  wheel  5 24 Jan 10:05 foo
kallisti:/tmp alex$ 
Quindi sembra proprio che ci sia una qualche "sincronizzazione" che
anche per la stessa applicazione succede se si apre col Finder ma non se
si apre con il terminale.
Il tempo di update non c'entra:
kallisti:/tmp alex$ ls -l foo
-rw-r--r--  1 alex  wheel  5 23 Jan 21:16 foo
quello e` corretto.  E cosi` pure quello di ultimo aggiornamento
esplicito dell'inode (spesso erroneamente chiamato "tempo di creazione"
da chi non capisce bene i filesystem Unix...):
kallisti:/tmp alex$ ls -lc foo
-rw-r--r--  1 alex  wheel  5 23 Jan 21:20 foo
Quella era l'ora cui ho eseguito touch (aggiornando quindi l'inode).
Dunque tutto corretto salvo il RITARDATO aggiornamento di atime dopo
letture da terminale.  Adesso lo rileggo poi ogni tanto quando mi
ricordo vedo quando si aggiorna l'atime... al momento:
kallisti:/tmp alex$ ls -lu foo
-rw-r--r--  1 alex  wheel  5 24 Jan 10:10 foo
kallisti:/tmp alex$ date
Mon Jan 24 10:12:29 CET 2005
kallisti:/tmp alex$ cat foo
ciao
kallisti:/tmp alex$ ls -lu foo
-rw-r--r--  1 alex  wheel  5 24 Jan 10:10 foo
Quindi dev'essere "pending" un aggiornamento dell'atime alle 10:12.
Non sono sicurissimo se c'entri o meno il journaling.  Io non ho mai
cambiato i settaggi di default del filesystem quindi non so neppure se
ce l'ho o meno... come si controlla?
Alex

 Quindi dev'essere "pending" un aggiornamento dell'atime alle 10:12.
Controllato adesso (10:21)...:
kallisti:/tmp alex$ ls -lu foo
-rw-r--r--  1 alex  wheel  5 24 Jan 10:15 foo
quindi l'aggiornamento dell'atime si e` avuto abbastanza presto ma non
e` pienamente accurato -- pare che rifletta il momento in cui si e`
appunto avuta la sincronizzazione, non quello 3 minuti prima in cui il
file era stato letto l'ultima volta.
Vabbe`, agli scopi di controllare quali file non siano stati letti da
mesi (che e` quello che chiedeva inizialmente questo thread!) qualche
minuto di eventuale errore sull'atime potrebbe non essere importante.
Se mai bisogna controllare che non ci siano processi che, ad esempio per
backup periodici, possano rileggere tutti i file e non rimettere
doverosamente a posto il loro atime, ad esempio; io non ne ho, ma nulla
di piu` facile che un programma di backup abbia questo problema.
Alex

 o abilitare il journaling.
OK, vedo che mi offre di fare un Disable quindi immagino cio` significa
che ce l'ho abilitato.
Alex

 poi perche' in questo caso non ci sia stato delay, nunzo'.
Nope: basta far partire TextEdit con
    open -e test
da Terminal -- e` la stessa applicazione ma il comportamento e` diverso.
Alex

 10.3.8
Aspetta e spera...
Comunque, per scoprire quali file non sono stati letti da MESI, penso
che atime vada comunque benone!
Alex