Pour les quotas : non, il n'y a pas de quotas de suppression.
Pour le problème: aucune idée vu que tu dis pas le problème, l'erreur, ...
Présenté comme ca je pourrais te répondre «parce que tu n'as pas du penser à taper rm $HOME/enlightenment/user_themes.cfg»...
J'ai déjà eu le cas, une fois, sur des machines de la fac, d'un fichier dont j'étais propriétaire et que je n'arrivais pas à effacer (étant propriétaire, je me suis pourtant assuré d'avoir les bons droits)... jamais pu trouver d'où ça venait ni réussi à le reproduire, je ne dois pas être doué.
Pour supprimer un fichier, ce ne sont pas les droits sur le fichier qui sont important, mais les droits sur le répertoire qui le contient.
En effet, si tu as les droits d'écriture sur un répertoire, tu peux en supprimer les fichiers même si tu n'a pas le droit de les modifier.
Donc ce sont les permissions du répertoire qui contient le fichier qu'il faut vérifier.
C'est vrai qu'il faut faire très attention avec ça, car le problème peut aussi arriver dans l'autre sens.
On pense qu'un fichier est protégé, et boom, plus de fichier (ça sent le vécu, c'est normal).
Quelqu'un sait-il d'ailleur le pourquoi de ceci. Je trouve ça en effet étrange comme principe. Est-ce une contraite technique, ou alors cela semblait logique lors de la conception des systèmes de fichiers.
De plus, est-il possible de protéger des fichiers contre l'effacement, mais pas ses voisins (ceux qui sont dans le même dossier).
C'est une conséquence de l'inplémentation du système.
Créer (lier, link) ou supprimer (délier, unlink) un fichier se fait dans le répertoire, on ajoute un fichier au répertoire et c'est bien ce dernier qui est modifié.
De plus, est-il possible de protéger des fichiers contre l'effacement, mais pas ses voisins (ceux qui sont dans le même dossier).
C'est à ça que sert le sticky bit sur les répertoires (pour les fichiers il est obsolète), extrait de la manpage de chmod:
"When the sticky bit is set on a directory, files in that directory may be unlinked or renamed only by root or their owner. Without the sticky bit, anyone able to write to the directory can delete or rename files. The sticky bit is commonly found on directories, such as /tmp, that are world-writable."
Faut pas trop t'inquiéter, Unix a des dizaines d'années d'expériences derrière lui, part du principe qu'il y a déjà un moyen de régler les problèmes que tu rencontre et cherche-les, souvent la réponse n'est pas si loin que ça ;-)
# Heu tu peux préciser ?
Posté par Pascal Terjan (site web personnel) . Évalué à 1.
Pour le problème: aucune idée vu que tu dis pas le problème, l'erreur, ...
Présenté comme ca je pourrais te répondre «parce que tu n'as pas du penser à taper rm $HOME/enlightenment/user_themes.cfg»...
[^] # Re: Heu tu peux préciser ?
Posté par Yusei (Mastodon) . Évalué à 2.
[^] # Re: Heu tu peux préciser ?
Posté par wismerhill . Évalué à 6.
En effet, si tu as les droits d'écriture sur un répertoire, tu peux en supprimer les fichiers même si tu n'a pas le droit de les modifier.
Donc ce sont les permissions du répertoire qui contient le fichier qu'il faut vérifier.
[^] # Re: Heu tu peux préciser ?
Posté par seginus . Évalué à 1.
On pense qu'un fichier est protégé, et boom, plus de fichier (ça sent le vécu, c'est normal).
Quelqu'un sait-il d'ailleur le pourquoi de ceci. Je trouve ça en effet étrange comme principe. Est-ce une contraite technique, ou alors cela semblait logique lors de la conception des systèmes de fichiers.
De plus, est-il possible de protéger des fichiers contre l'effacement, mais pas ses voisins (ceux qui sont dans le même dossier).
[^] # Re: Heu tu peux préciser ?
Posté par wismerhill . Évalué à 3.
Créer (lier, link) ou supprimer (délier, unlink) un fichier se fait dans le répertoire, on ajoute un fichier au répertoire et c'est bien ce dernier qui est modifié.
De plus, est-il possible de protéger des fichiers contre l'effacement, mais pas ses voisins (ceux qui sont dans le même dossier).
C'est à ça que sert le sticky bit sur les répertoires (pour les fichiers il est obsolète), extrait de la manpage de chmod:
"When the sticky bit is set on a directory, files in that directory may be unlinked or renamed only by root or their owner. Without the sticky bit, anyone able to write to the directory can delete or rename files. The sticky bit is commonly found on directories, such as /tmp, that are world-writable."
Faut pas trop t'inquiéter, Unix a des dizaines d'années d'expériences derrière lui, part du principe qu'il y a déjà un moyen de régler les problèmes que tu rencontre et cherche-les, souvent la réponse n'est pas si loin que ça ;-)
[^] # Re: Heu tu peux préciser ?
Posté par Ze Fredz . Évalué à 2.
# LOL
Posté par maxtoo . Évalué à -4.
[^] # Re: LOL
Posté par nicodache . Évalué à 2.
# miaou
Posté par alphacc . Évalué à 8.
l'option +s/-s peut etre.
verifie je me rappelle plus.
(et sur linuxfr.org il y a aussi des forums...)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.