Namen met een / synchroniseren

[Sylvester]

Ik heb ondertussen al het één en ander draaien op m'n nas, het één al met meer succes dan het ander.
Zo sync ik een folder tussen mijn Mac en de NAS. Dat gaat prima, maar hij 'verslikt' zich bij documenten en folders met namen waarin een / staat.
Op de NAS maakt hij dan een heel andere naam ervan, bijvoorbeeld 'B5OCA1~Y' in plaats van aaaa/bbbb
Het document klopt wel, maar de naam is anders.

Helaas heb ik veel documenten met een /, wat op een Mac geen probleem is.
Wat kan ik hiermee?
Is dat op te lossen, of een workaround ... ?

[Birdy]

Gebruik je op de MAC Cloud Station Drive ?
Zo ja, dan:

Standaard zal Cloud Station Drive geen bestanden en mappen back-uppen onder de volgende voorwaarden:
.
.
Voor Mac:

    De map of het bestandspad bevat de volgende tekens:
    \ /
    De map of het bestandspad meer dan 768 tekens telt.
    De bestandsnaam langer is dan 255 tekens.
    Het bestand behoort tot een van de volgende bestandstypes:
        Pictogram
        Socket
        Apparaatnode
        FIFO

Bron.

Zou geen workaround weten op dit moment behalve: geen \ / gebruiken in je bestandsnamen gebruiken maar, die wist je al.

[Hofstede]

Dat wordt heel lastig, want de '/' is voor Linux wat de '\' voor windows is. Dus het teken dat een sub-folder aangeeft.

[Briolet]

Ik denk dat de mac "onder water" ook geen / gebruikt omdat de mac op unix draait waar dat ook illegaal is.

Even getest. Als ik de map "testmap/met_slash" aanmaak is dat geen probleem. Maar als ik dan via de terminal naar de filenaam kijk, staat daar: "testmap:met_slash".

De slash in een naam wordt onder water als een dubbele punt opgeslagen. En juist dit teken mag je nu niet gebruiken via de finder. 

Op zich dan jammer day hij dat niet met de : erin naar de nas stuurt en daar zo opslaat. Maar dat zal dan wel weer een gereserveerd windows-teken zijn.

[Briolet]

Bij mij synchroniseert hij wel gewoon files met een "/" in de naam. Als ik via File station op de nas kijk, staat daar de file met een dubbele punt erin, maar als ik op de andere macs kijk, zie ik daar ook gewoon de slash. Zelfs als ik via een gemounte share op de nas kijk, zie ik de filenaam met een slash.

Misschien dat jij ook nog windows apparaten in je synchronisatie hebt, die de boel verzieken?

[Sylvester]

Nee, gelukkig geen Windows toestanden in de buurt.
Wel een aanzienlijk probleem want het zijn erg veel documenten die ik met een / heb.

Tja, nu zie ik nog een ander probleem : hij kopieert geen aliassen.
Geen ramp natuurlijk, want elders staan de originele documenten. Maar toch is de samenstelling van alle mappen een beetje om zeep.

Ik ben nieuw in dit gebeuren, en stiekem had ik toch gehoopt de er iets meer compatibiliteit met een Mac zou zijn.

[Briolet]

Een slash in een filenaam is gewoon een lastig teken. Ik vermijd het daarom altijd al. Vroeger (voor het OSX tijdperk) was de colon juist de scheiding in de folderstruktuur. Die was vroeger illegaal in filenamen en apple heeft dat blijkbaar zo gelaten voor de gebruiker toen ze naar Unix overgestapt zijn.

Interessant in dit verband is ook het volgende uit deze bron over de intergratie van Unix en Mac.

Another obvious problem is the different path separators between HFS+ (colon, ':') and UFS (slash, '/'). This also means that HFS+ file names may contain the slash character and not colons, while the opposite is true for UFS file names. This was easy to address, though it involves transforming strings back and forth. The HFS+ implementation in the kernel's VFS layer converts colon to slash and vice versa when reading from and writing to the on-disk format. So on disk the separator is a colon, but at the VFS layer (and therefore anything above it and the kernel, such as libc) it's a slash. However, the traditional Mac OS toolkits expect colons, so above the BSD layer, the core Carbon toolkit does yet another translation. The result is that Carbon applications see colons, and everyone else sees slashes. This can create a user-visible schizophrenia in the rare cases of file names containing colon characters, which appear to Carbon applications as slash characters, but to BSD programs and Cocoa applications as colons.

Dit artikel is wel 15 jaar oud.

[Sylvester]

Ja, maar jullie hebben het over / en :  die 'gewisseld' worden.

Maar wat ik zie gebeuren is iets anders (zie mijn eerste post) :
Als er een / in staat, wordt de naam VOLLEDIG onleesbaar veranderd.
Vreemd... of niet?

[Briolet]

Ik zie het verschil ook. Heb jij die slashes in de finder aangemaakt of via een ander programma. Misschien dat ze als unicode tekens opgeslagen zijn? (ik doe maar een wilde gok) en dat cloud station daar dan weer anders mee omgaat.

Wat gebeurt er als je de slash in de finder toevoegt (of de naam in de finder edit)?

[Sylvester]

Die / zijn gewoon in de finder in de naam van het document of map gezet of aangemaakt

Ik heb als test in de finder even een map met naam 'ACROBAT' veranderd in ACRO/BAT
Op een bepaald volume in de NAS maakt hij er dit van : AJ3NYE~V
Of ik dat nu bekijken via File Station op de NAS zelf, of op de Mac met het volume in de finder gemount , het is identiek.

Na verwijderen van / is de naam op de NAS terug in orde.

[Briolet]

Vreemd dat het bij mij dan anders werkt. Ik merk nu dat de files met een / niet naar mijn android telefoon synchroniseren.

[Ben(V)]

Op een Linux systeem is een / een forbidden karakter in een filenaam net zoals op bijna alle OS-en.
Op windows systemen zijn er nog een paar meer karakters die niet gebruikt mogen worden in een filenaam, te weten:

• < (less than)
• > (greater than)
• : (colon)
• " (double quote)
• / (forward slash)
• \ (backslash)
• | (vertical bar or pipe)
• ? (question mark)
• * (asterisk)

Het is dus altijd verstandig deze tekens nergens in een filenaam te gebruiken, want anders is bestandsuitwisseling tussen systemen altijd problematisch.

[Sylvester]

Ja daar zijn we nu achter, dat mijn zorgeloze leven met een Mac opeens niet meer zo zorgeloos is.

[Hofstede]

Tsja, daar kom je achter als je je Mac gaat gebruiken voor zaken die buiten de Apple eco-sfeer liggen. Dan wordt het allemaal net even moeilijker. Maar ook Windows heeft de nodige bijzonderheidjes in combinatie met Linux.

[Briolet]

Het enige wat mij intrigeert is waarom het bij mij wel werkt in een mac-only omgeving en bij Silvester niet.

Open voor de aardigheid eens het terminal programma op de mac en sleep dan zo'n file op het terminal window Als het goed is, vult hij dan het volledige pad naar de file in. Dan is het interessant om te zien hoe het daar staat. Dat geeft een beetje aan waar het verschil optreed. Is het in de finder al anders  of gebeurd het pas als cloud station de file verplaatst.