> Ainsi parlait kamel : > > ca y est ca marche (mais je trouve cela un peu tordue). merci encore de > > votre aide. C'est la premi�re fois que je rencontre ce genre de proc�dure: > > 1) Sur le serveur tftp > > touch file > > chmod 777 file > > 2) Sur le client > > # tftp tftp.domain.com > > tftp> put file > > Sent 31 bytes in 0.1 seconds > > > > y-a-t-il une explication quant � ce type de proc�dure ? > > y-a--t-il moyen de uploader un fichier sans avoir � la cr�er pr�alablement ? > > �a ressemble fortement � un probl�me de droit sur le r�pertoire qui > contient les fichiers. Sous Unix (et POSIX, je crois), pour ajouter ou > enlever des fichiers dans un r�pertoire, il faut avoir le droit en > �criture sur ce r�pertoire (sur le fichier qui se fait passer pour un > r�pertoire en fait). Par contre, si on a le droit d'�criture sur un > fichier contenu dans ce r�pertoire, on peut modifier son contenu mais > pas le supprimer. D'o� la n�cessit� de cr�er le fichier avant. > > A noter que l'on peut avoir aussi la situation inverse : pouvoir > modifier les entr�es du r�pertoire (suppression, ajout), mais ne pas > avoir le droit de modifier un fichier contenu dans ce r�pertoire. On > peut alors supprimer et recr�er le fichier, mais pas le modifier > directement. D�routant, non ? > > Voir : http://www.tldp.org/FAQ/Linux-FAQ/x1980.html#AEN2270 > > En bref, quels sont les droits sur le r�pertoire en question ? Ton > utilisateur tftp a-t-il la permission d'�crire dedans ? je r�pertoire poss�de les droits 777 mais un "put file" ne fonctionne depuis le client si et seulement si j'ai fait un touch file sur le serveur suivie d'un chmod 777 ou 666.
> -- > Charles > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] merci @+ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
