J'ai un problème assez étrange avec ma Mandrake 10 Official.
Sur une partition FAT32, lorsque je supprime un fichier avec Konqueror (je
n'ai pas essayé en utilisant rm), le fichier est bien supprimé, mais
l'espace libre de la partition reste inchangé. Le plus étrange est que cela
ne me le fait pas à chaque fois.
Pour que l'espace libre de la partition soit correctement recalculé, il faut
que je boot sous Windows 2000.
J'ai analysé la partition avec différents utilitaires (celui fournit avec
Windows 2000 et Norton Utilities) et il n'y a aucune erreur.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
thierry.rouillon
sanao nous a gentiment écrit:
Bonjour,
J'ai un problème assez étrange avec ma Mandrake 10 Official.
Sur une partition FAT32, lorsque je supprime un fichier avec Konqueror (je n'ai pas essayé en utilisant rm), le fichier est bien supprimé, mais l'espace libre de la partition reste inchangé. Le plus étrange est que cela ne me le fait pas à chaque fois.
Pour que l'espace libre de la partition soit correctement recalculé, il faut que je boot sous Windows 2000.
J'ai analysé la partition avec différents utilitaires (celui fournit avec Windows 2000 et Norton Utilities) et il n'y a aucune erreur.
Si quelqu'un avait une idée.
Merci d'avance. Je ne connais pas cette version mais ne serait ce pas un problème de
rafraichissement d'ecran -- Thierry de Champagne... l'adresse est fermée: Les bouteilles sont vides.
sanao nous a gentiment écrit:
Bonjour,
J'ai un problème assez étrange avec ma Mandrake 10 Official.
Sur une partition FAT32, lorsque je supprime un fichier avec Konqueror (je
n'ai pas essayé en utilisant rm), le fichier est bien supprimé, mais
l'espace libre de la partition reste inchangé. Le plus étrange est que
cela ne me le fait pas à chaque fois.
Pour que l'espace libre de la partition soit correctement recalculé, il
faut que je boot sous Windows 2000.
J'ai analysé la partition avec différents utilitaires (celui fournit avec
Windows 2000 et Norton Utilities) et il n'y a aucune erreur.
Si quelqu'un avait une idée.
Merci d'avance.
Je ne connais pas cette version mais ne serait ce pas un problème de
rafraichissement d'ecran
--
Thierry de Champagne... l'adresse est fermée: Les bouteilles sont vides.
J'ai un problème assez étrange avec ma Mandrake 10 Official.
Sur une partition FAT32, lorsque je supprime un fichier avec Konqueror (je n'ai pas essayé en utilisant rm), le fichier est bien supprimé, mais l'espace libre de la partition reste inchangé. Le plus étrange est que cela ne me le fait pas à chaque fois.
Pour que l'espace libre de la partition soit correctement recalculé, il faut que je boot sous Windows 2000.
J'ai analysé la partition avec différents utilitaires (celui fournit avec Windows 2000 et Norton Utilities) et il n'y a aucune erreur.
Si quelqu'un avait une idée.
Merci d'avance. Je ne connais pas cette version mais ne serait ce pas un problème de
rafraichissement d'ecran -- Thierry de Champagne... l'adresse est fermée: Les bouteilles sont vides.
sanao
Je ne connais pas cette version mais ne serait ce pas un problème de rafraichissement d'ecran Cela ne vient pas du tout de KDE. Lorsque j'utilise la commande df pour voir
l'espace libre. Ce dernier n'a pas changé alors que j'ai bien supprimer le fichier.
J'ai aussi essayé en utilisant la commande rm. Et une fois sur deux l'espace libre n'est pas correctement recalculé.
Le seul moyen de régler le problème est de redémarrer sous Windows. C'est loin d'être pratique...
A+
Je ne connais pas cette version mais ne serait ce pas un problème de
rafraichissement d'ecran
Cela ne vient pas du tout de KDE. Lorsque j'utilise la commande df pour voir
l'espace libre. Ce dernier n'a pas changé alors que j'ai bien supprimer le
fichier.
J'ai aussi essayé en utilisant la commande rm. Et une fois sur deux l'espace
libre n'est pas correctement recalculé.
Le seul moyen de régler le problème est de redémarrer sous Windows. C'est
loin d'être pratique...
Je ne connais pas cette version mais ne serait ce pas un problème de rafraichissement d'ecran Cela ne vient pas du tout de KDE. Lorsque j'utilise la commande df pour voir
l'espace libre. Ce dernier n'a pas changé alors que j'ai bien supprimer le fichier.
J'ai aussi essayé en utilisant la commande rm. Et une fois sur deux l'espace libre n'est pas correctement recalculé.
Le seul moyen de régler le problème est de redémarrer sous Windows. C'est loin d'être pratique...
A+
françois
sanao wrote:
Je ne connais pas cette version mais ne serait ce pas un problème de rafraichissement d'ecran
Cela ne vient pas du tout de KDE. Lorsque j'utilise la commande df pour voir l'espace libre. Ce dernier n'a pas changé alors que j'ai bien supprimer le fichier.
J'ai aussi essayé en utilisant la commande rm. Et une fois sur deux l'espace libre n'est pas correctement recalculé.
Le seul moyen de régler le problème est de redémarrer sous Windows. C'est loin d'être pratique...
A+
Salut ,
ce n'est qu'une suggestion ,mais cela est peut-être du à l'algo spécifique du noyau linux concernant l'ecriture et la supression de fichiers différé :selon la charge de l'ordi ,mémoire et autre, ces deux actions peuvent être remis à plus tard et c'est pour cela que tu as ce phénomène (de plus il ne se reproduit pas à chaque fois).
Sur disquette par exemple ,lorsque tu fait une écriture (ou donc une suppression ) tu peux t'aperçevoir que l'action n'est effectuée que lors du démontage (tous ce qui est entrepris ne l'est qu'en mémoire ),ou en utilisant la commande sync (synchronisation)(man sync) , cela est pareil pour tous périphériques: dd et autres clé usb....
sanao wrote:
Je ne connais pas cette version mais ne serait ce pas un problème de
rafraichissement d'ecran
Cela ne vient pas du tout de KDE. Lorsque j'utilise la commande df pour voir
l'espace libre. Ce dernier n'a pas changé alors que j'ai bien supprimer le
fichier.
J'ai aussi essayé en utilisant la commande rm. Et une fois sur deux l'espace
libre n'est pas correctement recalculé.
Le seul moyen de régler le problème est de redémarrer sous Windows. C'est
loin d'être pratique...
A+
Salut ,
ce n'est qu'une suggestion ,mais cela est peut-être du à
l'algo spécifique du noyau linux concernant l'ecriture et
la supression de fichiers différé :selon la charge de l'ordi
,mémoire et autre, ces deux actions peuvent être remis à
plus tard et c'est pour cela que tu as ce phénomène
(de plus il ne se reproduit pas à chaque fois).
Sur disquette par exemple ,lorsque tu fait une écriture (ou donc une
suppression ) tu peux t'aperçevoir que l'action n'est effectuée
que lors du démontage (tous ce qui est entrepris ne l'est qu'en mémoire
),ou en utilisant la commande sync (synchronisation)(man sync) ,
cela est pareil pour tous périphériques: dd et autres clé usb....
Je ne connais pas cette version mais ne serait ce pas un problème de rafraichissement d'ecran
Cela ne vient pas du tout de KDE. Lorsque j'utilise la commande df pour voir l'espace libre. Ce dernier n'a pas changé alors que j'ai bien supprimer le fichier.
J'ai aussi essayé en utilisant la commande rm. Et une fois sur deux l'espace libre n'est pas correctement recalculé.
Le seul moyen de régler le problème est de redémarrer sous Windows. C'est loin d'être pratique...
A+
Salut ,
ce n'est qu'une suggestion ,mais cela est peut-être du à l'algo spécifique du noyau linux concernant l'ecriture et la supression de fichiers différé :selon la charge de l'ordi ,mémoire et autre, ces deux actions peuvent être remis à plus tard et c'est pour cela que tu as ce phénomène (de plus il ne se reproduit pas à chaque fois).
Sur disquette par exemple ,lorsque tu fait une écriture (ou donc une suppression ) tu peux t'aperçevoir que l'action n'est effectuée que lors du démontage (tous ce qui est entrepris ne l'est qu'en mémoire ),ou en utilisant la commande sync (synchronisation)(man sync) , cela est pareil pour tous périphériques: dd et autres clé usb....
gaasmann
"françois" a écrit dans le message de news: IUwic.15621$
sanao wrote:
ce n'est qu'une suggestion ,mais cela est peut-être du à l'algo spécifique du noyau linux concernant l'ecriture et la supression de fichiers différé :selon la charge de l'ordi ,mémoire et autre, ces deux actions peuvent être remis à plus tard et c'est pour cela que tu as ce phénomène (de plus il ne se reproduit pas à chaque fois).
Si tu le peux, démonte puis remonte ta partition et vérifie à nouveau ton espace disque pour en avoir le coeur net.
a+
-- Gaasmann
"françois" <francois.dimo@hotmail.coml> a écrit dans le message de news:
IUwic.15621$N9.8452@news.chello.at...
sanao wrote:
ce n'est qu'une suggestion ,mais cela est peut-être du à
l'algo spécifique du noyau linux concernant l'ecriture et
la supression de fichiers différé :selon la charge de l'ordi
,mémoire et autre, ces deux actions peuvent être remis à
plus tard et c'est pour cela que tu as ce phénomène
(de plus il ne se reproduit pas à chaque fois).
Si tu le peux, démonte puis remonte ta partition et vérifie à nouveau ton
espace disque pour en avoir le coeur net.
"françois" a écrit dans le message de news: IUwic.15621$
sanao wrote:
ce n'est qu'une suggestion ,mais cela est peut-être du à l'algo spécifique du noyau linux concernant l'ecriture et la supression de fichiers différé :selon la charge de l'ordi ,mémoire et autre, ces deux actions peuvent être remis à plus tard et c'est pour cela que tu as ce phénomène (de plus il ne se reproduit pas à chaque fois).
Si tu le peux, démonte puis remonte ta partition et vérifie à nouveau ton espace disque pour en avoir le coeur net.
a+
-- Gaasmann
no_spam
On Sat, 24 Apr 2004 16:49:44 +0000, françois wrote:
sanao wrote:
Je ne connais pas cette version mais ne serait ce pas un problème de rafraichissement d'ecran
Cela ne vient pas du tout de KDE. Lorsque j'utilise la commande df pour voir l'espace libre. Ce dernier n'a pas changé alors que j'ai bien supprimer le fichier.
J'ai aussi essayé en utilisant la commande rm. Et une fois sur deux l'espace libre n'est pas correctement recalculé.
Le seul moyen de régler le problème est de redémarrer sous Windows. C'est loin d'être pratique...
A+
Salut ,
ce n'est qu'une suggestion ,mais cela est peut-être du à l'algo spécifique du noyau linux concernant l'ecriture et la supression de fichiers différé :selon la charge de l'ordi ,mémoire et autre, ces deux actions peuvent être remis à plus tard et c'est pour cela que tu as ce phénomène (de plus il ne se reproduit pas à chaque fois).
Les actions physiques sont différées mais le kernel sait que les fichiers ont été supprimés et les statistiques du file-system ne sont pas affectées par le système de cache. Ce n'est donc pas celà qui intèrfère. Pour s'en convaincre: dd if=/dev/urandom of=/tmp/test count=xxx df /tmp ; sync ; df /tmp rm -f /tmp/test df /tmp ; sync ; df /tmp l'espace libre sera bien mis à jour avant les sync.
Par contre, si quelqu'un utilise les fichiers en question, ceux-ci sont marqués effacés mais l'espace correspondant n'est libéré que quand le fichier est fermé: sinon, l'utilisateur du fichier aurait des erreurs alléatoires ou des donnnées incohérentes. C'est le seul cas, je crois, ou l'espace n'est pas libéré au moment du rm.
On Sat, 24 Apr 2004 16:49:44 +0000, françois wrote:
sanao wrote:
Je ne connais pas cette version mais ne serait ce pas un problème de
rafraichissement d'ecran
Cela ne vient pas du tout de KDE. Lorsque j'utilise la commande df pour voir
l'espace libre. Ce dernier n'a pas changé alors que j'ai bien supprimer le
fichier.
J'ai aussi essayé en utilisant la commande rm. Et une fois sur deux l'espace
libre n'est pas correctement recalculé.
Le seul moyen de régler le problème est de redémarrer sous Windows. C'est
loin d'être pratique...
A+
Salut ,
ce n'est qu'une suggestion ,mais cela est peut-être du à
l'algo spécifique du noyau linux concernant l'ecriture et
la supression de fichiers différé :selon la charge de l'ordi
,mémoire et autre, ces deux actions peuvent être remis à
plus tard et c'est pour cela que tu as ce phénomène
(de plus il ne se reproduit pas à chaque fois).
Les actions physiques sont différées mais le kernel sait que les
fichiers ont été supprimés et les statistiques du file-system ne sont
pas affectées par le système de cache.
Ce n'est donc pas celà qui intèrfère.
Pour s'en convaincre:
dd if=/dev/urandom of=/tmp/test count=xxx
df /tmp ; sync ; df /tmp
rm -f /tmp/test
df /tmp ; sync ; df /tmp
l'espace libre sera bien mis à jour avant les sync.
Par contre, si quelqu'un utilise les fichiers en question, ceux-ci
sont marqués effacés mais l'espace correspondant n'est libéré que
quand le fichier est fermé: sinon, l'utilisateur du fichier aurait
des erreurs alléatoires ou des donnnées incohérentes.
C'est le seul cas, je crois, ou l'espace n'est pas libéré au moment
du rm.
On Sat, 24 Apr 2004 16:49:44 +0000, françois wrote:
sanao wrote:
Je ne connais pas cette version mais ne serait ce pas un problème de rafraichissement d'ecran
Cela ne vient pas du tout de KDE. Lorsque j'utilise la commande df pour voir l'espace libre. Ce dernier n'a pas changé alors que j'ai bien supprimer le fichier.
J'ai aussi essayé en utilisant la commande rm. Et une fois sur deux l'espace libre n'est pas correctement recalculé.
Le seul moyen de régler le problème est de redémarrer sous Windows. C'est loin d'être pratique...
A+
Salut ,
ce n'est qu'une suggestion ,mais cela est peut-être du à l'algo spécifique du noyau linux concernant l'ecriture et la supression de fichiers différé :selon la charge de l'ordi ,mémoire et autre, ces deux actions peuvent être remis à plus tard et c'est pour cela que tu as ce phénomène (de plus il ne se reproduit pas à chaque fois).
Les actions physiques sont différées mais le kernel sait que les fichiers ont été supprimés et les statistiques du file-system ne sont pas affectées par le système de cache. Ce n'est donc pas celà qui intèrfère. Pour s'en convaincre: dd if=/dev/urandom of=/tmp/test count=xxx df /tmp ; sync ; df /tmp rm -f /tmp/test df /tmp ; sync ; df /tmp l'espace libre sera bien mis à jour avant les sync.
Par contre, si quelqu'un utilise les fichiers en question, ceux-ci sont marqués effacés mais l'espace correspondant n'est libéré que quand le fichier est fermé: sinon, l'utilisateur du fichier aurait des erreurs alléatoires ou des donnnées incohérentes. C'est le seul cas, je crois, ou l'espace n'est pas libéré au moment du rm.
françois
no_spam wrote:
Bonjour ,
Les actions physiques sont différées mais le kernel sait que les fichiers ont été supprimés et les statistiques du file-system ne sont pas affectées par le système de cache. Ce n'est donc pas celà qui intèrfère. Pour s'en convaincre: dd if=/dev/urandom of=/tmp/test count=xxx df /tmp ; sync ; df /tmp rm -f /tmp/test df /tmp ; sync ; df /tmp l'espace libre sera bien mis à jour avant les sync.
Pour ma part , merci pour la précision , c'était un peu vague .
Par contre, si quelqu'un utilise les fichiers en question, ceux-ci sont marqués effacés mais l'espace correspondant n'est libéré que quand le fichier est fermé: sinon, l'utilisateur du fichier aurait des erreurs alléatoires ou des donnnées incohérentes. C'est le seul cas, je crois, ou l'espace n'est pas libéré au moment du rm.
Donc dans le cas de Sanao le problème ne vient pas de là , à moins qu'il ai ouvert ouvert le même fichier plusieurs fois (?). Peut-être que le module fat est foireux , je ne pense pas non plus ,j'en ai pas entendu parlé (faut voir google).
no_spam wrote:
Bonjour ,
Les actions physiques sont différées mais le kernel sait que les
fichiers ont été supprimés et les statistiques du file-system ne sont
pas affectées par le système de cache.
Ce n'est donc pas celà qui intèrfère.
Pour s'en convaincre:
dd if=/dev/urandom of=/tmp/test count=xxx
df /tmp ; sync ; df /tmp
rm -f /tmp/test
df /tmp ; sync ; df /tmp
l'espace libre sera bien mis à jour avant les sync.
Pour ma part , merci pour la précision , c'était un peu vague .
Par contre, si quelqu'un utilise les fichiers en question, ceux-ci
sont marqués effacés mais l'espace correspondant n'est libéré que
quand le fichier est fermé: sinon, l'utilisateur du fichier aurait
des erreurs alléatoires ou des donnnées incohérentes.
C'est le seul cas, je crois, ou l'espace n'est pas libéré au moment
du rm.
Donc dans le cas de Sanao le problème ne vient pas de là , à moins
qu'il ai ouvert ouvert le même fichier plusieurs fois (?).
Peut-être que le module fat est foireux , je ne pense pas non plus
,j'en ai pas entendu parlé (faut voir google).
Les actions physiques sont différées mais le kernel sait que les fichiers ont été supprimés et les statistiques du file-system ne sont pas affectées par le système de cache. Ce n'est donc pas celà qui intèrfère. Pour s'en convaincre: dd if=/dev/urandom of=/tmp/test count=xxx df /tmp ; sync ; df /tmp rm -f /tmp/test df /tmp ; sync ; df /tmp l'espace libre sera bien mis à jour avant les sync.
Pour ma part , merci pour la précision , c'était un peu vague .
Par contre, si quelqu'un utilise les fichiers en question, ceux-ci sont marqués effacés mais l'espace correspondant n'est libéré que quand le fichier est fermé: sinon, l'utilisateur du fichier aurait des erreurs alléatoires ou des donnnées incohérentes. C'est le seul cas, je crois, ou l'espace n'est pas libéré au moment du rm.
Donc dans le cas de Sanao le problème ne vient pas de là , à moins qu'il ai ouvert ouvert le même fichier plusieurs fois (?). Peut-être que le module fat est foireux , je ne pense pas non plus ,j'en ai pas entendu parlé (faut voir google).
no_spam
On Sun, 25 Apr 2004 13:36:20 +0000, françois wrote:
no_spam wrote:
Par contre, si quelqu'un utilise les fichiers en question, ceux-ci sont marqués effacés mais l'espace correspondant n'est libéré que quand le fichier est fermé: sinon, l'utilisateur du fichier aurait des erreurs alléatoires ou des donnnées incohérentes. C'est le seul cas, je crois, ou l'espace n'est pas libéré au moment du rm.
Donc dans le cas de Sanao le problème ne vient pas de là , à moins qu'il ai ouvert ouvert le même fichier plusieurs fois (?).
Il suffit qu'il soit ouvert une fois, et pas encore fermé au moment du rm...
Peut-être que le module fat est foireux , je ne pense pas non plus ,j'en ai pas entendu parlé (faut voir google).
C'est extrèmement peu probable: c'est un des file-system les plus testés de Linux. A moins que ce ne soit pas un kernel standard et que les patches appliqués soient la cause du bug... Pour savoir, il faut tester avec un kernel officiel...
On Sun, 25 Apr 2004 13:36:20 +0000, françois wrote:
no_spam wrote:
Par contre, si quelqu'un utilise les fichiers en question, ceux-ci
sont marqués effacés mais l'espace correspondant n'est libéré que
quand le fichier est fermé: sinon, l'utilisateur du fichier aurait
des erreurs alléatoires ou des donnnées incohérentes.
C'est le seul cas, je crois, ou l'espace n'est pas libéré au moment
du rm.
Donc dans le cas de Sanao le problème ne vient pas de là , à moins
qu'il ai ouvert ouvert le même fichier plusieurs fois (?).
Il suffit qu'il soit ouvert une fois, et pas encore fermé au moment
du rm...
Peut-être que le module fat est foireux , je ne pense pas non plus
,j'en ai pas entendu parlé (faut voir google).
C'est extrèmement peu probable: c'est un des file-system les plus
testés de Linux. A moins que ce ne soit pas un kernel standard et
que les patches appliqués soient la cause du bug...
Pour savoir, il faut tester avec un kernel officiel...
On Sun, 25 Apr 2004 13:36:20 +0000, françois wrote:
no_spam wrote:
Par contre, si quelqu'un utilise les fichiers en question, ceux-ci sont marqués effacés mais l'espace correspondant n'est libéré que quand le fichier est fermé: sinon, l'utilisateur du fichier aurait des erreurs alléatoires ou des donnnées incohérentes. C'est le seul cas, je crois, ou l'espace n'est pas libéré au moment du rm.
Donc dans le cas de Sanao le problème ne vient pas de là , à moins qu'il ai ouvert ouvert le même fichier plusieurs fois (?).
Il suffit qu'il soit ouvert une fois, et pas encore fermé au moment du rm...
Peut-être que le module fat est foireux , je ne pense pas non plus ,j'en ai pas entendu parlé (faut voir google).
C'est extrèmement peu probable: c'est un des file-system les plus testés de Linux. A moins que ce ne soit pas un kernel standard et que les patches appliqués soient la cause du bug... Pour savoir, il faut tester avec un kernel officiel...
sanao
Salut,
Après quelques test, j'ai enfin résolu le problème.
Voilà l'explication : Les fichiers que je supprimais se trouvaient sur une partition et cette partition était utilisée par MLdonkey, les fichiers étaient donc ouverts. Le fait de les supprimer alors qu'ils étaient ouverts ne libérait donc pas l'espace libre tant que les fichiers n'étaient pas fermés.
J'avais oublié de dire que les fichiers qui n'étaient vraiment supprimés pouvaient réapparaitre au bout d'un certains temps dans la fenêtre de Konqueror avec une taille de 0 octet. Je ne sais pas si c'est un problème de Konqueror ou de Linux vu que je n'ai pas pensé à faire un ls. Maintenant j'ai la flemme de refaire des tests pour trouver d'où vient le problème, ça restera donc un mystère! ;-)
Quoiqu'il en soit, mon problème est maintenant réglé (MLdonkey ne partage plus la partition). Merci à tous pour votre aide.
A+
Salut,
Après quelques test, j'ai enfin résolu le problème.
Voilà l'explication :
Les fichiers que je supprimais se trouvaient sur une partition et cette
partition était utilisée par MLdonkey, les fichiers étaient donc ouverts.
Le fait de les supprimer alors qu'ils étaient ouverts ne libérait donc pas
l'espace libre tant que les fichiers n'étaient pas fermés.
J'avais oublié de dire que les fichiers qui n'étaient vraiment supprimés
pouvaient réapparaitre au bout d'un certains temps dans la fenêtre de
Konqueror avec une taille de 0 octet. Je ne sais pas si c'est un problème
de Konqueror ou de Linux vu que je n'ai pas pensé à faire un ls. Maintenant
j'ai la flemme de refaire des tests pour trouver d'où vient le problème, ça
restera donc un mystère! ;-)
Quoiqu'il en soit, mon problème est maintenant réglé (MLdonkey ne partage
plus la partition). Merci à tous pour votre aide.
Après quelques test, j'ai enfin résolu le problème.
Voilà l'explication : Les fichiers que je supprimais se trouvaient sur une partition et cette partition était utilisée par MLdonkey, les fichiers étaient donc ouverts. Le fait de les supprimer alors qu'ils étaient ouverts ne libérait donc pas l'espace libre tant que les fichiers n'étaient pas fermés.
J'avais oublié de dire que les fichiers qui n'étaient vraiment supprimés pouvaient réapparaitre au bout d'un certains temps dans la fenêtre de Konqueror avec une taille de 0 octet. Je ne sais pas si c'est un problème de Konqueror ou de Linux vu que je n'ai pas pensé à faire un ls. Maintenant j'ai la flemme de refaire des tests pour trouver d'où vient le problème, ça restera donc un mystère! ;-)
Quoiqu'il en soit, mon problème est maintenant réglé (MLdonkey ne partage plus la partition). Merci à tous pour votre aide.
