verboden karakters in bestandsnaam bij kopiëren

[Beekhof]

Erg lastig bij backuppen van een reeks bestanden (500) naar een MyBookWorld NAS systeem (MBW), is dat de copy/paste actie stopt zodra er een " : # karakter gezien wordt en daardoor de volgende bestanden niet op te slaan zijn op die MBW (NTFS, netwerk verbinding).
Dit zelfde levert bij normale copy/paste geen enkel probleem, bv.op de Desktop van Ubuntu.
Ook 't kopiëren naar een USB stick of HD. Ook hier is NTFS het file systeem.

Waarom blokkeert die MBW dan wel problematisch.
De opslag op MBW is naar Public en Anonimus.

Nu moet zo'n lastige file eerst herneemt worden, maar stopt het kopieervproces Wer bij de volgende bestandsnaam met "verboden" karakters er in.

Is er een script te verzinnen waardoor het proces niet hapert.
Toepassen van de command Line (CLI) is geen bezwaar, maar hoe?

[Beekhof]

Tenslotte bleken er ook enige PDF files overgezet te zijn, maar bleken bij poging tot openen een (speciaal) wacht woord wordt vereist, terwijl die file voordien gewoon leesbaar was, raar maar waar.
Waarom en welke trucks nodig?

[HarzG]

NTFS accepteert sommige tekens  niet, het zijn '\0' (NUL) en '/', verder zijn  \ : * ? " < > | ook niet toegestaan.
Als dat wel lukt om naar een NTFS-USB-stick deze bestanden met "vreemde tekens"  te kopiëren, dan is dat voor mij onbegrijpelijk. Het is voor mij de vraag of je bestanden met zulke tekens met een Windows systeem kan openen.
Met # heb ik ook geen positieve ervaringen (bedrijfsnetwerk), hoewel dat volgens mij niet als officieel verboden te boek staat.
In je Ubuntu-systeem zijn voor de bestandsnamen de karakters '\0' (NUL) en '/' niet toegestaan.

Als je tussen verschillende bestandssystemen ext4 en NTFS bestanden gaat uitwisselen, moet je de restricties van beide bestandssystemen kennen en daarna handelen als je namen aanmaakt.
Ik weet dat ik onder 14.04  afbeeldingen kon maken met Prt-Sc die in de naam een ':' hadden bij de tijdsaanduiding. Dat is nu bij mij niet meer zo (16.04), daar worden '-' tekens voor gebruikt.

De oplossing zit in een script wat naar deze bestandsnamen zoekt en dat vervolgens corrigeert. Ik heb niet gezocht, maar er is ongetwijfeld ergens een script hiervoor gemaakt.

[jan11000]

Files zippen en op de bestemming uitpakken.
Alleen lost dit je probleem niet op tav rare tekens in de files.

[vanadium]

Als dat wel lukt om naar een NTFS-USB-stick deze bestanden met "vreemde tekens"  te kopiëren, dan is dat voor mij onbegrijpelijk. Het is voor mij de vraag of je bestanden met zulke tekens met een Windows systeem kan openen.

Dat is niet onbegrijpelijk op zich. nfts-3g laat het gebruik van die vreemde karakters toe. Je komt dan wel in de problemen als je die schijf later aan een Windows systeem hangt, want Windows laat die karakters niet toe. Terwijl ntfs-3g dat niet doet, controleert de NAS blijkbaar wel of de bestandsnamen aan de Windows conventies voldoen.

De verantwoordelijkheid correcte namen voor je doel-besturingssysteem te gebruiken, wordt dus aan de arme gebruiker overgelaten. Even opletten in de naamgeving, dus.

Je zou een find commando kunnen gebruiken om illegale karakters systematisch uit een bestandsnaam te kunnen weren.

Code: [Selecteer]

find . -execdir rename -n 's/\:/\./g' "{}" \;
[code]
Dit commando vindt elk bestand/folder in de huidige directory en vervangt ":" door ".". Ik heb hier de -n optie toegevoegd zodat je kunt testrijden: met die optie hernoem je het bestand nog niet, maar wordt er enkel getoond hoe het bestand zou hernoemd worden met de opgegeven opties. Verwijder de "-n" na rename om het hernoemen effectief door te voeren.

Je herhaalt dat een aantal keer voor de andere vreemde karakters. 's/\:/\./g' ziet er ingewillend uit, maar omvat vier velden, gescheiden door /. Eerste veld: s, betekent: zoek. Tweede veld: \: duidt het dubbele punt aan, met name de tekst die wordt gezocht. Derde veld: \. staat voor een punt, namelijk de tekst die de zoektekst zal vervangen (vul hier in wat je wil in de plaats van de :. Kan je ook leeglaten.), vierde veld "g" geeft aan dat alle gevonden tekens, niet enkel het eerste, vervangen moeten worden.   


[Beekhof]

 Vanadium: Alleen bij die MyBookWorld heb ik dit probleem en Inderdaad is dit Windows (program Mionet) georienteerd!
De oplossing is om deze (slechts weinige files, 10 op 500) m.b.v. van cmd find  op te zoeken en weg te filteren of te wijzigen (vooraf aan copy/paste, wat ik wel eens "schuiven" noem), dank voor je script.

In een ander shell-script over backup gaf je aan IMAP mail uit te sluiten (--excl in RSync).
Is mijn interpretatie juist: Imap mail zijn bij de mail-provider opgeslagen en die kun je beter daar telkens weer ophalen.
Ik merkte nl. na upgrade van Ub10.04 naar Ub12.04 en opnieuw installeren van Thunderbird deze elders opgeslagen mails in een razend tempo weer opgehaald worden.   
 

[vanadium]

In een ander shell-script over backup gaf je aan IMAP mail uit te sluiten (--excl in RSync).
Is mijn interpretatie juist: Imap mail zijn bij de mail-provider opgeslagen en die kun je beter daar telkens weer ophalen.
Ik merkte nl. na upgrade van Ub10.04 naar Ub12.04 en opnieuw installeren van Thunderbird deze elders opgeslagen mails in een razend tempo weer opgehaald worden.   

De imap folders sluit  ik uit omdat backup ervan geen zin heeft en de backup uiteraard sneller gaat als je die om die reden niet mee neemt. De imap folders zijn slechts locale "caches" van de folders op de server.

[HarzG]

... en de naam bevat een : van de bestanden die in de locale cache staan zoals bijv.  "/home/user/Maildir/cur/1387553594.V6805I335cfdM892800.debian:2,S"