[Linux NAS] Een bestand met speciale tekens te verwijderen?

[iAR]

Ik heb iets gedownload op mijn NAS, en de map heeft een vaag teken in zijn naam. Hij is door de web-filemanager of mijn mac niet te verwijderen. Cyberduck geeft de error dat het een reference voor een bestand dat niet bestaat is.
Anyway, hoe krijg ik dat bestand weg?

Ik heb de volgende tip geprobeerd: http://www.cyberciti.biz/...es-with-inode-number.html

Maar ik krijg in de terminal een help van find terug... werkt dus niet.
Iemand een oplossing?

[bassie]

code:

$ find . -inum 782263 -exec rm -i {} \;

Moet precies in die volgorde. Bij find -inum xxx . krijg je een usage melding omdat je het path eerst komt.

[iAR]

bassie schreef op woensdag 20 oktober 2010 @ 20:04:

code:

$ find . -inum 782263 -exec rm -i {} \;

Moet precies in die volgorde. Bij find -inum xxx . krijg je een usage melding omdat je het path eerst komt.

Wat gaat er hier mis dan?

code:

sh-3.2# ls -il
25116676 drwxrwxrwx    3 admin    administ     4096 Aug 17 17:14 Sven_V?th;

sh-3.2# find . -inum 25116676 -exec rm -i {} \;

BusyBox v1.01 (2010.07.19-17:25+0000) multi-call binary

Usage: find [PATH...] [EXPRESSION]

Search for files in a directory hierarchy.  The default PATH is
the current directory; default EXPRESSION is '-print'

EXPRESSION may consist of:
    -follow     Dereference symbolic links.
    -name PATTERN   File name (leading directories removed) matches PATTERN.
    -print      Print (default and assumed).

    -type X     Filetype matches X (where X is one of: f,d,l,b,c,...)
    -perm PERMS Permissions match any of (+NNN); all of (-NNN);
            or exactly (NNN)
    -mtime TIME Modified time is greater than (+N); less than (-N);
            or exactly (N) days

sh-3.2#

[MacGrumpy]

busybox find ondersteund niet alle opties.

correct escapen zou moeten werken. Dan kan je het gewoon met de hand.
b.v.

mkdir "test?"
rm -r test\?

Je shell zal dan niet proberen ? te resolven/expanden (of hoe je dat noemt.)

[Rainmaker]

oZner schreef op woensdag 20 oktober 2010 @ 22:19:
[...]

Wat gaat er hier mis dan?

code:

sh-3.2# ls -il
25116676 drwxrwxrwx    3 admin    administ     4096 Aug 17 17:14 Sven_V?th;

Het feit dat je op busybox zit...

Zit je op een embedded ding oid?

In dit geval moet dit ook werken:

code:

rm 'Sven_V?th;'

[silentsnake]

Het volledige pad opgeven wil ook nog wel eens een optie zijn, eventueel met quotes of escapen.

[Big Mama]

Het is een directory, dus wel de optie -r (van rm) gebruiken.

[swbr]

Volgens mij moet je ook gewoon vanaf een terminal op je mac die find opdracht kunnen geven. Het is niet voor niets Unix^tm

Als aanvulling op wat hier eerder is gezegd, als je op je NAS zelf de '-inum' optie van find niet hebt, dan zou je iets kunnen doen als:

code:

find . -name Sven\*
find . -name Sven\* -exec rm -rf {} \;

Een goed gebruik is om een find altijd eerst zonder de '-exec' riedel te doen, dan krijg je eerst te zien waar je je commando allemaal op los gaat laten...

[sparks]

met wildcards moet het ook wel lukken. wel even testen met een ls -d om zeker te zijn dat je niet iets soortgelijks verwijderd.

[deadinspace]

Wat een moeilijk gedoe hier allemaal...
Wat is er mis met

rmdir Sven_V?th\;

?

[ Voor 3% gewijzigd door deadinspace op 21-10-2010 19:48 ]

[Rainmaker]

deadinspace schreef op donderdag 21 oktober 2010 @ 19:48:
Wat een moeilijk gedoe hier allemaal...
Wat is er mis met

rmdir Sven_V?th\;

?

Dat het vraagteken eventueel door bash ge-expand wordt

En dat de directory waarschijnlijk niet leeg is.

Dus;

code:

rm -rf 'Sven_V?th;'

[deadinspace]

Rainmaker schreef op donderdag 21 oktober 2010 @ 21:58:
Dat het vraagteken eventueel door bash ge-expand wordt

Dus? Een vraagteken staat voor een willekeurig karakter, en dat matcht natuurlijk ook een letterlijk vraagteken.

Los daarvan omschreef de TS het als "een vaag teken", dus de kans is heel groot dat het geen letterlijk vraagteken is, maar een non-printable character dat door ls als '?' getoond wordt omdat het non-printable is. In dat geval werkt het juist niet als je het vraagteken escaped.

En dat de directory waarschijnlijk niet leeg is.

Nou, dan maaktie er rm -r van. Maar als die directory niet leeg is, dan wil hij juist misschien eerst kijken wat er nog in staat...

[TJVB]

En als er verder nu niks met Sven begint kun je toch gewoon rm -r Sven* of wordt het nu echt te laat voor mij?

[iAR]

Het is inderdaad geen vraagteken, maar in de finder een zwart ruitje met vraagteken. Of de map echt leeg is weet ik niet, Cyberduck en Finder zeggen van wel...!? Hij kan hoe dan ook weg!

Uiteindelijk is de naam nog wat langer, rm -r sven* zou dan goed klinken, ware het niet als ik dat zo invoer dat ik terug krijg: no such file or directory. Alle andere linux/unix commando's laten me een beetje in de steek (zo ervaren ben ik daar niet in).

Enne BusyBox? Duidelijk een beperking, maar wat is het?

[Kees]

oZner schreef op vrijdag 22 oktober 2010 @ 09:24:
Het is inderdaad geen vraagteken, maar in de finder een zwart ruitje met vraagteken. Of de map echt leeg is weet ik niet, Cyberduck en Finder zeggen van wel...!? Hij kan hoe dan ook weg!

Uiteindelijk is de naam nog wat langer, rm -r sven* zou dan goed klinken, ware het niet als ik dat zo invoer dat ik terug krijg: no such file or directory. Alle andere linux/unix commando's laten me een beetje in de steek (zo ervaren ben ik daar niet in).

Enne BusyBox? Duidelijk een beperking, maar wat is het?

en rm -rf Sven* dan? (in je ls zie ik het met een hoofdletter staan).

Of als de dir verder leeg is; rm -r * - of zelfs cd ..; rm -rf $dir

[swbr]

Wat is het volledige path van die directory? Als het iets is als /data/muziek/Sven_V?th, dan zou je kunnen proberen om de parent directory weg te mikken (wel zorgen dat er verder niets anders meer onder staat natuurlijk).

[Rainmaker]

deadinspace schreef op donderdag 21 oktober 2010 @ 23:35:
[...]

Dus? Een vraagteken staat voor een willekeurig karakter, en dat matcht natuurlijk ook een letterlijk vraagteken.

De was omdat je anders ook bestanden verwijderd die Sven_Vath;, Sven_Veth; e.d. heten. En je gaat natuurlijk niet meer data verwijderen dan dat je wil. De kans hierop zal 0.00001% zijn, maar toch

Wat betreft dat non-printable character, kun je heel goed gelijk hebben.

[iAR]

Kees schreef op vrijdag 22 oktober 2010 @ 10:03:
[...]

en rm -rf Sven* dan? (in je ls zie ik het met een hoofdletter staan).

Of als de dir verder leeg is; rm -r * - of zelfs cd ..; rm -rf $dir

Ok, ik voel me nu enigszins dom... Natuurlijk nooit aan die hoofdletter gedacht. Dat en het sterretje waren de truc > rm -r Sven*

[DutchNutcase]

oZner schreef op vrijdag 29 oktober 2010 @ 17:04:
[...]

Ok, ik voel me nu enigszins dom... Natuurlijk nooit aan die hoofdletter gedacht. Dat en het sterretje waren de truc > rm -r Sven*

Ach ja, dat is de makkelijkste manier om nooit meer te vergeten dat *nix caps-sensitive is.

[Verwijderd]

oZner schreef op vrijdag 22 oktober 2010 @ 09:24:
Het is inderdaad geen vraagteken, maar in de finder een zwart ruitje met vraagteken. Of de map echt leeg is weet ik niet, Cyberduck en Finder zeggen van wel...!? Hij kan hoe dan ook weg!

Uiteindelijk is de naam nog wat langer, rm -r sven* zou dan goed klinken, ware het niet als ik dat zo invoer dat ik terug krijg: no such file or directory. Alle andere linux/unix commando's laten me een beetje in de steek (zo ervaren ben ik daar niet in).

Enne BusyBox? Duidelijk een beperking, maar wat is het?

BusyBox wordt op embedded systemen gebruikt, het is een gecompileerd bestand waarbij je tijdens het compileren aangeeft welke tools het moet bevatten, door symlinks voor alle meegecompileerde tools te maken kun je alle tools gewoon aanroepen met de gebruikelijke command line.

Omdat het gericht is op embedded systemen (waar opslag en rekenkracht vaak beperkt zijn) zijn de tools niet allemaal volledig geimplementeerd.

Hoop het zo een beetje goed uitgelegd te hebben , misschien dat er iemand nog wat aan toe kan voegen?

[deepbass909]

Ik zit met hetzelfde probleem... Alleen werken de trucs die hier genoemd worden geen van allen...
De map die het probleem oplevert is de volgende:
[code](1999) 't Beste Van 2 Werelden[/]

Hierin zitten 2 karakters die echt roet in het eten gooien, namelijk de ' en de \ (ja, die slash maakt echt deel uit van de bestandsnaam...)
Vooral de ' vormt een probleem, want wat ik ook probeer, bash interpreteert het bij elke poging als een escape-karakter...

Hoe kan ik deze map toch weg?

edit:
kleine toevoeging. Bij elke poging die ik doe, krijg ik de volgende fout:

code:

rmdir: kan './(1999) 't Beste Van 2 Werelden\\' niet verwijderen: Toegang geweigerd

Dit is de output van ls -il:

code:

roodhaar Rowwen Hèze # ls -il
totaal 16
34702259 drwxr-xr-x 2 chris users 4096 okt 24 20:16 (1995) Zondag In 't Zuiden
34702260 drwxr-xr-x 2 chris users 4096 nov 14 03:35 (1997) Water, Lucht En Liefde
34702261 drwxr-xr-x 2 chris users 4096 nov 16 01:33 (1999) 't Beste Van 2 Werelden\
34702262 drwxr-xr-x 2 chris users 4096 nov 14 03:35 (2000) Vandaag

Ik probeer uiteraard als root-gebruiker het weg te krijgen, dus van een rechtenprobleem is geen sprake. Maar ook als gebruiker "chris", de eigenaar, krijg ik hem niet weg...

[ Voor 43% gewijzigd door deepbass909 op 16-11-2010 21:24 ]

[blaataaps]

Is de directory leeg?

[deepbass909]

De directory was leeg. Het probleem heeft zich inmiddels opgelost. Om de één of andere reden trok mijn media-player (waar de map op stond) zich niks aan van de foute karakters en wou de map wel verwijderen. Dit verbaast mij wel, aangezien de media-player (een Popcorn Hour C-200) ook linux draait en dus eigenlijk ook last zou moeten hebben van dezelfde karakters...

Maar het is al opgelost.

Al ben ik wel benieuwd hoe je een dergelijke map nou onder linux wel weg kan krijgen.

[vanaalten]

deepbass909 schreef op dinsdag 16 november 2010 @ 22:35:
Al ben ik wel benieuwd hoe je een dergelijke map nou onder linux wel weg kan krijgen.

Escapen tot je er bij neervalt?

code:

~/tmp/tmp3$ ls -l
total 0
~/tmp/tmp3$ touch \(1999\)\ \'t\ Beste\ Van\ 2\ Werelden\\
~/tmp/tmp3$ ls -l
total 0
-rw-r--r-- 1 vanaalten vanaalten 0 Nov 17 08:40 (1999) 't Beste Van 2 Werelden\
~/tmp/tmp3$ rm \(1999\)\ \'t\ Beste\ Van\ 2\ Werelden\\
~/tmp/tmp3$ ls -l
total 0

Ofwel, in een lege directory met touch die file van jou aanmaken en daarna met rm weer verwijderen. Geen enkel probleem mee...

[Tim]

man 2 rmdir zegt:

EACCES Write access to the directory containing pathname was not allowed,  or  one
              of the directories in the path prefix of pathname did not allow search per‐
              mission.  (See also path_resolution(7).
EPERM  The  directory containing pathname has the sticky bit (S_ISVTX) set and the
              process's effective user ID is neither the  user  ID  of  the  file  to  be
              deleted  nor  that  of  the directory containing it, and the process is not
              privileged (Linux: does not have the CAP_FOWNER capability).

Dus waarschijnlijk stonden de rechten op de parent directory niet goed. Je hebt ook kans dat je media player het wel kon verwijderen, omdat in plaats van te verwijderen, die de map heeft verplaatst naar Trash.

[deepbass909]

vanaalten schreef op woensdag 17 november 2010 @ 08:43:
[...]

Escapen tot je er bij neervalt?

code:

~/tmp/tmp3$ ls -l
total 0
~/tmp/tmp3$ touch \(1999\)\ \'t\ Beste\ Van\ 2\ Werelden\\
~/tmp/tmp3$ ls -l
total 0
-rw-r--r-- 1 vanaalten vanaalten 0 Nov 17 08:40 (1999) 't Beste Van 2 Werelden\
~/tmp/tmp3$ rm \(1999\)\ \'t\ Beste\ Van\ 2\ Werelden\\
~/tmp/tmp3$ ls -l
total 0

Ofwel, in een lege directory met touch die file van jou aanmaken en daarna met rm weer verwijderen. Geen enkel probleem mee...

Het was een directory, geen bestand. En escapen tot je erbij neervalt heb ik geprobeerd (lang leve bash-completion), maar dat werkte dus ook niet.

Tim schreef op woensdag 17 november 2010 @ 10:46:
man 2 rmdir zegt:

EACCES Write access to the directory containing pathname was not allowed,  or  one
              of the directories in the path prefix of pathname did not allow search per‐
              mission.  (See also path_resolution(7).
EPERM  The  directory containing pathname has the sticky bit (S_ISVTX) set and the
              process's effective user ID is neither the  user  ID  of  the  file  to  be
              deleted  nor  that  of  the directory containing it, and the process is not
              privileged (Linux: does not have the CAP_FOWNER capability).

Dus waarschijnlijk stonden de rechten op de parent directory niet goed. Je hebt ook kans dat je media player het wel kon verwijderen, omdat in plaats van te verwijderen, die de map heeft verplaatst naar Trash.

Voor zover ik nu nog na kan gaan, waren beiden niet aan de orde, tenminste, niet bewust. Ik had dezelfde map ook op een NAS staan, waar hij niet weg wou, en die NAS zet zelf alle permissies, zonder dat je er als gebruiker invloed op kan uitoefenen (soms best wel irritant...)
Dat laatste kan een mogelijkheid zijn, hoewel verplaatsen ook niet wou. Iets wat mij nu te binnenschiet, is dat het mogelijk aan de locale-instellingen heeft gelegen. Ik gebruik op mijn vaste pc (als het goed is) UTF-8, maar wat mijn media-player gebruikt, weet ik zo niet.

Overigens liep ik later tegen nog een paar bestanden aan, waarmee ik vergelijkbare problemen had omdat er een "?" in de bestandsnaam stond. Via een NSF- of SAMBA-share kreeg ik deze niet verplaatst, hernoemd of verwijderd, maar over ftp wel. Dus het probleem lijkt mij vooral in het gebruikte protocol en codering die mijn apparatuur gebruikt binnen dat protocol... FTP staat namelijk ook geforceerd op UTF-8, en die werkte wel...

[vanaalten]

deepbass909 schreef op woensdag 17 november 2010 @ 10:59:
Het was een directory, geen bestand. En escapen tot je erbij neervalt heb ik geprobeerd (lang leve bash-completion), maar dat werkte dus ook niet.

File, directory; maakt niets uit. Mijn voorbeeld werkt evengoed met files als directories.
Ik denk dat de filename niet het issue was, maar eerder misschien een 'lock' door het bestandsysteem of zo.

[deepbass909]

Op 2 totaal verschillende plaatsen op apparaten die minimaal 1 reboot hebben gehad tussentijds? Een lock is wel het laatste wat het had kunnen veroorzaken...

Lokaal heb ik ook geen problemen met "rare" bestandsnamen, maar juist op de netwerkshares gaat het blijkbaar fout.

[deadinspace]

De foutmelding was op zich toch vrij duidelijk:

deepbass909 schreef op dinsdag 16 november 2010 @ 21:17:

code:

rmdir: kan './(1999) 't Beste Van 2 Werelden\\' niet verwijderen: Toegang geweigerd

Je had dus niet de rechten om het te verwijderen, wat niks met eventuele karakters in de filename te maken heeft. Misschien was hij immutable?

vanaalten schreef op woensdag 17 november 2010 @ 11:53:
Ik denk dat de filename niet het issue was, maar eerder misschien een 'lock' door het bestandsysteem of zo.

Een lock lijkt me sterk. Mandatory locks zijn ongebruikelijk op Unices, en beschermen vziw niet tegen unlink.