Verwijderen bestanden/mappen met rf-commando

[I_stealth_I]

Ik heb een directory op mijn Redhat bak die ik graag weg zou willen hebben. Normaal kan ik me prima redden met rm -rf en de mappen + files + onderliggende dirs gaan keurig weg.

Maar nu krijg ik het dus absoluut niet voormekaar om die directory te trashen! Ik heb van alles ondernomen met rm -rfd mapnaam/ en vele variaties daarop.

code:

[root@localserver Temporary stuff]# rm -rf pukkel
rm: cannot remove directory `pukkel/backup/21-06-02/admin/faq': Map niet leeg
rm: cannot remove directory `pukkel/backup/21-06-02/admin': Map niet leeg
rm: cannot remove directory `pukkel/backup/21-06-02': Map niet leeg
rm: cannot remove directory `pukkel/backup': Map niet leeg
rm: cannot remove directory `pukkel': Map niet leeg
[root@localserver Temporary stuff]# 
[root@localserver Temporary stuff]# rm -rfd pukkel
rm: cannot unlink `pukkel': Is een map
[root@localserver Temporary stuff]# cd pukkel                       
[root@localserver pukkel]# rm -rf
[root@localserver pukkel]# ls
backup
[root@localserver pukkel]# rm -rfd
[root@localserver pukkel]# ls
backup
[root@localserver pukkel]# rm -rfd backup
rm: cannot unlink `backup': Is een map
[root@localserver pukkel]# 
[root@localserver pukkel]# cd backup/21-06-02/admin/faq
[root@localserver faq]# rm -rf *
[root@localserver faq]# rm -rf  
[root@localserver faq]# ls
ls:  t/Ä01.gif: Onbekend bestand of map
[root@localserver faq]# rm -rf t/Ä01.gif
[root@localserver faq]# ls
ls:  t/Ä01.gif: Onbekend bestand of map
[root@localserver faq]#

Ik snap niet wat er aan de hand is hoor. Filesystem brak

[sebas]

lijkt er eigenlijk meer op dat of je rm brak is of dat die de argumenten niet meekrijgt.

[Hagar]

midnight commander is misschien wel makkelijk

[sebas]

die maakt denk ik ook gebruik van rm, bovendien lost dat het probleem niet echt op.

[Buffy]

Hoei, een bestandsnaam met een '/' erin (staat de kernel dat toe?).

Die ga je niet weg krijgen met standaard unix tools omdat die unlink(<filename>) doen en bij het vertalen van de filename naar inode de '/' als directory scheidings teken wordt gezien waardoor het bestand niet gevonden wordt (of de verkeerde ).

Denk dat je hiervoor een filesystem editor moet gebruiken om dat goed te krijgen (bv debugfs voor ext2, lees wel eerst de man page).
En voer ook eens een filesystem check uit, just in case

[luc]

try "rm t\/Ä01.gif"

[I_stealth_I]

luc schreef op 17 augustus 2002 @ 03:35:
try "rm t\/Ä01.gif"

Ik heb het ingegeven, kijk maar ffies mee

code:

[root@localserver faq]# rm -f t\/Ä01.gif
[root@localserver faq]# ls
ls:  t/Ä01.gif: Onbekend bestand of map
[root@localserver faq]#

Gaat ook niet echt.

[Verwijderd]

I_Stealth_I schreef op 17 augustus 2002 @ 09:55:
[...]
[root@localserver faq]# rm -f t\/Ä01.gif

Is dat wel een V ? of een backslash+slash?
Probeer anders eens $ rm -i *gif

[TD-er]

ik denk dat je de file eerst moet proberen te renamen.
Voor het renamen hoeft het hele pad namelijk niet door de shell langsgelopen te worden, voor deleten wel. (zo is het in elk geval in Minix, waar ik Symlinks geïmplementeerd heb voor een practicum)
Renamen gaat heel makkelijk in Midnightcommander, maar ok wel met
mv t\/Ä01.gif bla

[I_stealth_I]

Verwijderd schreef op 17 augustus 2002 @ 10:06:
[...]

Is dat wel een V ? of een backslash+slash?
Probeer anders eens $ rm -i *gif

code:

[root@localserver faq]# rm -i *gif
rm: cannot remove ` t/Ä01.gif': Onbekend bestand of map
[root@localserver faq]# rm -i *gif
rm: cannot remove ` t/Ä01.gif': Onbekend bestand of map
[root@localserver faq]# rm -irf *gif
[root@localserver faq]# ls
ls:  t/Ä01.gif: Onbekend bestand of map
[root@localserver faq]#

Het wordt dus niet als een bestand gezien. Ook via mijn Secure FTP explorer wordt dat bestand niet zichtbaar, zelfs niet als verborgen bestand.

[I_stealth_I]

TD-er schreef op 17 augustus 2002 @ 10:17:
ik denk dat je de file eerst moet proberen te renamen.
Voor het renamen hoeft het hele pad namelijk niet door de shell langsgelopen te worden, voor deleten wel. (zo is het in elk geval in Minix, waar ik Symlinks geïmplementeerd heb voor een practicum)
Renamen gaat heel makkelijk in Midnightcommander, maar ok wel met
mv t\/Ä01.gif bla

code:

[root@localserver faq]# mv t\/Ä01.gif bla
mv: cannot stat `t/Ä01.gif': Onbekend bestand of map
[root@localserver faq]#

Word nie als bestand herkend

[TD-er]

run eens een fschk. Mischien dat die de inode wel weer vrij kan maken.
Aan de andere kant heb ik ook wel eens meegemaakt dat een dergelijke file door Samba weggehaald kon worden, dus via netwerk vanuit windows

[Onno]

Als je t<tab> doet ipv zelf de naam in te typen escapet bash 'm zelf zoals hij denk dat het goed is.. dat wil nog wel eens nuttige dingen opleveren.

[Verwijderd]

TD-er schreef op 17 augustus 2002 @ 10:26:
run eens een fschk. Mischien dat die de inode wel weer vrij kan maken.

Hmm, ik lees ook net dat een slash in een filename niet valid is, en dus ook niet kan worden verwijderd (zonder harde maatregelen, schijnt met hardlinking te kunnen), en dus in de eerste instantie ook al niet gecreerd had mogen worden... (las ik in nieuwsgroep)

[Verwijderd]

In article <[e-mail]> you write:

> shouldn't something like: rm "slash/file"
> work OK?

This won't work. The / is not interpreted by the shell, but by the
kernel routine namei(), which translates file names into inode numbers.
The interpretation of the / character is wired into namei()'s brain.
Any solution which involves using the unlink() system call to remove the
file will fail because namei() will gag on that /. I've never had to
deal with this problem before, but I seem to remember hearing a
solution. Please wizards, don't flame me if I'm wrong, I'm only a
wizard in training. Just politely point out my mistake and we'll all be
happy. Anyway, if you "ls -i" in the directory containing this bogon
file, you'll get the inode number for it. You can then use the clri
command to zap this inode. This will leave all the links which pointed
to this inode hanging loose, including the bogon link. It will also
leave all the blocks associated with the file "missing," i.e. they won't
be on the free list and the won't be allocated to files. After you run
clri, unmount the filesystem and run fsck on it to repair the damage.
This should get rid of all the hanging links and place the lost blocks
on the free list. BTW, you'd better do this in single-user mode so no
one will have open files on the filesystem when you try to dismount it,
otherwise you won't be able to dismount it. Be sure to read the man
pages for clri and fsck before you do any of this.

Donald L. Nash

The University of Texas System
Office of Telecommunication Services

Internet: [e-mail]
THEnet: THENIC::DON
BITNET: DON@THENIC
PSI Mail: 311051200131::DON

[TD-er]

Ik heb ff gekeken op 2 computers hier en nog een ander op zijn compu, maar geen van allen heeft dat clri
Ik denk toch dat je het via samba moet gaan proberen. Zo heb ik ook wel eens files weggekregen die ik niet via de shell weg kreeg.
Het is op zich namelijk best wel eng, wat er via dat samba protocol mogelijk is. Ik heb eens een schijf compleet onleesbaar kunnen maken (niet opzettelijk) via het netwerk en de eigen computer kon het niet meer lezen, maar de andere computers op het netwerk wel.
Na een reboot lukte dat uiteraard niet meer. Maar het geeft wel aan dat er hele vage dingen mogelijk zijn via het netwerk.

[majornono]

Sebas schreef op 17 augustus 2002 @ 03:22:
die maakt denk ik ook gebruik van rm, bovendien lost dat het probleem niet echt op.

Midnight commander maakt geen gebruik van rm, doet hij helemaal zelf.
Ik had ooit een rm -rf / gedaan, en toen was mijn hele bin dir weg. Geen rm meer dus. Maar midnight commander, geinstalleerd in /usr/bin deed het prima, inclusief de ftp verbindingen om bij een vriend van me met hetzelfde linux systeempje de complete bin dir weer terug te zetten

[Verwijderd]

waarom doe je dan ook rm -rf /?

[Buffy]

I_Stealth_I schreef op 17 augustus 2002 @ 10:21:
[...]

code:

[root@localserver faq]# mv t\/Ä01.gif bla
mv: cannot stat `t/Ä01.gif': Onbekend bestand of map
[root@localserver faq]#

Word nie als bestand herkend

Dit is toch logisch elke routine die een bestandsnaam mee krijgt met een slash erin zal denken dat er een pad mee wordt bedoeld ipv een bestandnaam.

Dus bv 'ls' vraagt de inhoud van de directory op en krijgt dan de bestandsnaam
' t/Ä01.gif' (staat nog een spatie voor ook) en vraagt dan de stat gegevens op en krijgt dan te horen dat bestand 'Ä01.gif' in directory ' t' niet bestaat.

Elk programma dat gebruik maakt van de standaard file routines zal dit probleem hebben.
Enkel programma's die op inode niveau werken zullen dit kunnen oplossen.


PS: Het heeft dus niks met shell escaping te maken want dan had je het kunnen oplossen m.b.v.

code:

ls -i
find -inum XXXX -exec rm {} \;

waarbij XXXX het inode nummer is dat 'ls -i' opgaf.

[Buffy]

TD-er schreef op 17 augustus 2002 @ 10:49:
Ik heb ff gekeken op 2 computers hier en nog een ander op zijn compu, maar geen van allen heeft dat clri
[..]

Als je even 'man debugfs' doet zie je daar het commando 'clri' staan (wel de man page lezen voor je het gebruikt )

[I_stealth_I]

Probleem is verholpen door even de betreffende schijf te unmounten en er een scan op los te laten. Vervolgens kwam dat rare bestand naar boven en heb ik het laten repareren. Nu was het wel mogelijk de map te verwijderen.

Bedankt voor reacties Thanks _Tornado_

Case closed!

[Verwijderd]

Case closed je moet er dan wel ff bij zetten wie het ff voor je gefixt heeft he )

Ja snel je bericht editen he doe ik ook nooit

[Verwijderd]

TD-er schreef op 17 augustus 2002 @ 10:49:
Ik heb ff gekeken op 2 computers hier en nog een ander op zijn compu, maar geen van allen heeft dat clri
Ik denk toch dat je het via samba moet gaan proberen. Zo heb ik ook wel eens files weggekregen die ik niet via de shell weg kreeg.
Het is op zich namelijk best wel eng, wat er via dat samba protocol mogelijk is. Ik heb eens een schijf compleet onleesbaar kunnen maken (niet opzettelijk) via het netwerk en de eigen computer kon het niet meer lezen, maar de andere computers op het netwerk wel.
Na een reboot lukte dat uiteraard niet meer. Maar het geeft wel aan dat er hele vage dingen mogelijk zijn via het netwerk.

Erg vreemd, aangezien Samba ook gewoon gebruik maakt van de normale fs-functies etc

Samba protocol ligt gewoon bovenop het fs. Het is niet zo dat de bestanden fysiek compleet anders benaderd worden o.i.d. hoor

[Verwijderd]

Verwijderd schreef op 18 augustus 2002 @ 19:34:

[...]

Erg vreemd, aangezien Samba ook gewoon gebruik maakt van de normale fs-functies etc

Samba protocol ligt gewoon bovenop het fs. Het is niet zo dat de bestanden fysiek compleet anders benaderd worden o.i.d. hoor

Stealth had dit ook al geprobeerd. werkte niet.

[Buffy]

Verwijderd schreef op 18 augustus 2002 @ 19:34:

[...]

Erg vreemd, aangezien Samba ook gewoon gebruik maakt van de normale fs-functies etc

Samba protocol ligt gewoon bovenop het fs. Het is niet zo dat de bestanden fysiek compleet anders benaderd worden o.i.d. hoor

Aan die A-umlaut te zien lijkt het me eerder een hardware glitch of kernel bug.
Tenzij hij natuurlijk duitse porno heeft zitten downloaden, dan heb ik niks gezegd

[I_stealth_I]

Dawns_sister schreef op 18 augustus 2002 @ 23:00:
[...]


Aan die A-umlaut te zien lijkt het me eerder een hardware glitch of kernel bug.
Tenzij hij natuurlijk duitse porno heeft zitten downloaden, dan heb ik niks gezegd

ROFLOL, nee dat is meestal JPG-formaat. Dit was roch echt GIF

[I_stealth_I]

Verwijderd schreef op 18 augustus 2002 @ 19:34:

[...]

Erg vreemd, aangezien Samba ook gewoon gebruik maakt van de normale fs-functies etc

Samba protocol ligt gewoon bovenop het fs. Het is niet zo dat de bestanden fysiek compleet anders benaderd worden o.i.d. hoor

Inderdaad, maar denk dat mijn HD brak aan het worden. Dit servertje draait zo'n 28 dagen en is in tussentijd nooit reset o.i.d. Dus kan eigenlijk nooit gekomen zijn door het niet-netjes afsluiten. HD brak of toch idd. kernel bug ?