Newsgroup: it.comp.programmare
Titolo: syscall unlink su linux

Salve a tutti,
vi espongo subito il mio problema:
sto scrivendo un programma in C che tra le varie cose mi crea 3 file
temporanei.Dopo questa fase li devo racchiudere in un archivio(io uso
zip ma penso sia indifferente).Infine devo cancellare i tre file
utilizzati e chiamo la unlink(char * path) sui tre file.Il problema è
che non riesco a farli sparire.Ho provato anche con la remove(char *
path) e non va(in teoria dovrebbe essere proprio la stessa funzione.
Qualcuno sa che può essere ? Non vorrei ricorrere a lanciare una exec
per rimuovere il file.
Grazie
Matteo

 che non riesco a farli sparire.
Immagino che unlink ritorni -1.
Hai controllato il valore di errno?
Poi (scusa se la domanda puo' sembrare scema) ma li hai chiusi i 3
file prima di chiamare unlink?
Saluti,
The Librarian

 file prima di chiamare unlink?
Se i files non sono lockati, la unlink dovrebbe cancellarli anche se 
qualche applicazione li ha in quel momento aperti.
Credo che questa cosa di poter cancellare i files aperti dipenda molto 
dal sistema operativo, piu' che dalla unlink().
Fermo restando che chiuderli prima di cancellarli, quei files, sarebbe 
decisamente opportuno.
Non dovrebbe essere una questione di permissions se i files li ha creati 
lui.
Solo l'esame dell'errno puo' aiutarci a risolvere il mistero.

 Solo l'esame dell'errno puo' aiutarci a risolvere il mistero.
Fatto,ma non restituisce nessun tipo di errore (o meglio:la perror non
mi dà output)
Grazie dell'aiuto
Ciao

 mi dà output)
Non so che dire.
Prova a simulare un single-step inserendo una getc() tra una riga e 
l'altra, cosi' l'esecuzione si ferma ad ogni riga e aspetta un invio.
E nel frattempo guardi che cosa succede...


Non posso :)
Grazie per la dritta cmq
Matteo

 Non posso :)
Se ci sono esigenze di sicurezza, probabilmente la unlink() e' 
insufficiente per cancellare i files senza lasciare traccia sul disco.
Quando si ha a che fare con crittografia, password o cose del genere, si 
tende a lavorare in ram, per non lasciare tracce recuperabili sul disco.
E comunque la soluzione di chiamare un processo esterno per zippare si 
presta ad un enorme buco di sicurezza: io posso rinominare lo zip e 
sostituirlo con un eseguibile finto che aspetta e non fa niente.
Il tuo processo crea i files, poi chiama il mio zip, e io ho tutto il 
tempo per accedere alla /tmp e leggere i files...
E non venirmi a dire come faccio a sapere che chiama lo zip o che i 
files stanno in /tmp, perche' la sicurezza non deve basarsi sull'ignoranza.
In altre parole, se devi fare le cose, cerca di farle bene.

 spostare anche di directory.
     Rename() causes the link named from to be renamed as to.  If to
     exists, it is first removed.  Both from and to must be of the same
     type (that is, both directories or both non-directories), and must
     reside on the same file system.
Può. Purchè si sia nello stesso filesystem. In realtà se consideri il
'nome' del file come tutto il path la cosa diventa più chiara. Peraltro
la rename agisce anche su directory (in modo prevedibile, visto che
tutto è un file).
-- 
blog:  
http://www.akropolix.net/rik0/blogs
 | Uccidete i filosofi,
site:  
http://www.akropolix.net/rik0/
      | tenetevi riso e
forum: 
http://www.akropolix.net/forum/
     | bacchette per voi.

 i thread non li conosco benissimo
e non ti serve conoscerli per questo.


Perfetto,risolto con un fork() del processo.
una cosa tipo:
if ((fd=fork())==0){
execvp(....);
exit (0);
}
else wait();
Grazie a tutti per l'aiuto....a presto
Matteo
On 11 Mag, 01:18, 
r...@despammed.com
 (Enrico 'Mc Osten' Franchi)
wrote:


 presta ad un enorme buco di sicurezza:
Non se lo genero io: nulla mi vieta di *emettere* il programma zippante
da qualche parte e di usare quello che ho appena creato.
Ma tipicamente direi che qui le esigenze non sono quelle. Anche perchč
poi una volta che č stato creato lo zip... che sicurezza c'č?
Se uno vuole fare il furbino craccare la crittografia di un zip č
parecchio piů semplice che manomettere un sistema e sostituire un
eseguibile.


 eseguibile.
Dipende...
Ad ogni modo, come ho detto in precedenza in un'altra risposta, se 
prorpio si vuole fare una cosa, la si deve fare bene, soprattutto nel 
campo della security: altrimenti la gente che non conosce queste 
problematiche restera convinta che fare lo XOR con una parola chiave sia 
un ottimo sistema di crittografia.

 campo della security.
Una cosa la si deve fare bene: ma se la sicurezza *non* è un problema (e
se ti stai archiviando i dati in un archivio zip la sicurezza *non* è un
problema), non vuole dire che stai facendo le cose male.


 Sempre che tu conosca il suo nome. Cosa che non è affatto scontata.
Il che vuole dire che 'puoi intercettare il file se ne conosci il nome'.


 problema), non vuole dire che stai facendo le cose male.
Se la sicurezza non e' un problema, nel caso in questione, torno a 
chiedermi come mai non ha risolto il suo problema con 3 righe di shell...
Poi pero' sento te che mi dici che avresti anche tu spostato, zippato e 
cancellato i files usando l'eseguibile e non uno script, e allora va 
bene cosi': e' solo questione di come uno e' abituato a lavorare.

 (o analoga per il formato
che usa) abbastanza semplice/comoda, vuole meno problemi possibili in
deployment... chessò.


 else wait();
Entro tardi nella discussione, ma mi pare che non sia ancora ben
chiaro un concetto: le funzioni della famiglia exec()
**sostituiscono** completamente il processo. Questo fa si' che:
1) sia necessaria una fork(), come giustamente e' venuto fuori, per
poter fare altre azioni
2) il codice successivo alla execvp() verra' eseguito solo e soltanto
quando la execvp() fallisca. Il che rende piuttosto stupido uscire con
stato '0'...
'
Quindi una cosa tipo:
if(fork()==0){
	execvp();
	int e=errno;
	perror("Error in execvp()");
	exit(errno);
}else{
	int e;
	int p=wait(&e);
	if(e != 0){
		printf("Child %d exited with status %d\n",p,e);
	}
}