speciale tekens en lange naam op een windows share via mac

[Multispeed]

Je hebt
mac sharing
windows sharing

mac sharing kan iets van 9 tekens maar ook speciale tekens zoals / of *
windows sharing kan veeel meer tekens maar geen speciale tekens.

Nu is dit een probleem want ze willen op de mac afdeling het beste van allebei. Nu is daar wel iets voor maar dat is beta en ik ga er geen beta opzetten.

Ik wil dus gewoon via een mac kunnen werken met lange bestandsnamen en speciale tekens
een combo van
mac sharing en windows sharing
en dat mag geen beta software zijn

waarom?? omdat ze bijvoorbeeld willen
klant a en klant b voor klant c via d die wil rood / wit iplv blauw / geel
en dat dan als filename

Aanvulling voor iemand
de client is mac en draait mac os 10
de server is windows 2003

dus als er een oplossing voor is om toch lange namen en speciale tekens op windows 2003 te kunnen doen.

[ Voor 14% gewijzigd door Multispeed op 17-12-2004 12:11 ]

[chem]

Gouldian schreef op vrijdag 17 december 2004 @ 11:48:
Je hebt
mac sharing
windows sharing

Je hebt wel meer dan dat. Met Mac sharing ( ) bedoel je waarschijnlijk AFP?

mac sharing kan iets van 9 tekens maar ook speciale tekens zoals / of *

Uh nee, AFP heeft een 32-char limiet.

windows sharing kan veeel meer tekens maar geen speciale tekens.

Nu is dit een probleem want ze willen op de mac afdeling het beste van allebei. Nu is daar wel iets voor maar dat is beta en ik ga er geen beta opzetten.

En wat is "dat"?

Ik wil dus gewoon via een mac kunnen werken met lange bestandsnamen en speciale tekens
een combo van
mac sharing en windows sharing
en dat mag geen beta software zijn

waarom?? omdat ze bijvoorbeeld willen
klant a en klant b voor klant c via d die wil rood / wit iplv blauw / geel
en dat dan als filename

Aanvulling voor iemand
de client is mac en draait mac os 10
de server is windows 2003

dus als er een oplossing voor is om toch lange namen en speciale tekens op windows 2003 te kunnen doen.

Heb je al naar andere protocollen gekeken?

Dit is nl. een algemeen bekend probleem - verschillende OS'en, verschillende protocollen - je komt uiteindelijk op de laagste gemene deler uit om het allemaal aan de praat te krijgen.

[leon1e]

Speciale tekens van de mac is echt het eerste wat je moet verbieden, een / wil je echt niet in directory namen zeker niet als je wilt uitwisselen met een pc. En om nog maar niet over een backup restore te spreken.

Maar als je het echt wilt, dan kun je dave voor de mac een proberen. Deze draait bovenop de ralle smb van mac os x, hiermee connect je dan op smb niveau maar met de resource fork en andere optie's van apl. Mischien kan deze ook speciale tekens aan, maar beter is het maken van keuzes en gewoon universeel zonder deze tekens gaan werken.

Toevoeging:

Lange namen kunnen wel, maar dan in combinatie met smb. En raad eens ,dan werken de speciale tekens niet meer. Je moet dat bedrijf gewoon 2 voorstellen doen, en duidelijk uitwerken waarom ze beter niet meer die speciale tekens kunnen gebruiken (uitwisseling bv.).

[Multispeed]

Tjah het maakt me niet uit hoe zolang het maar wil op een goede niet beta manier

een ander protocol zou ket ook kunnen oplossen iemand ideen ?

het probleem is dat er verschillende mac versies zijn dus het moet gewoon globaal werken

verschillende mac's en 1 server OS windows server 2003

[chem]

Heb je eigenlijk enig idee waar je mee bezig bent?
"verschillende mac's", dat klinkt als "verschillende dell's".
Bedoel je verschillende OS'en? Bv Classic en OS X? Of verschillende OS X versies?
Heb je al uitgezocht of bv NFS een oplossing biedt? Heb je eigenlijk uberhaupt al gezocht? Welke tool stellen zij voor die in beta is? Waarom heb je iets tegen beta software? Zijn er andere vergelijkbare tools die niet in beta zijn?

[Hydraulik-Phunk]

Dan de hamvraag; wie gebruikt er nu filenames als "klant a en klant b voor klant c via d die wil rood / wit iplv blauw / geel.html" ????

Sorry hoor, maar ik zou eerder naar de oorzaak van je probleem kijken dan 't gevolg van een kromme oplossing.
Als je nu gewoon 'professionele' bestandnamen gebruikt en een beschrijvingsfile in tekstformaat er bij legt lijkt mij dat de problemen de wereld uit zijn.
Die lange bestandnamen mogen wel werken onder Windows, maar ook dan kan je nog tegen rare problemen oplopen is mijn ervaring.

Een bestandsnaam is niet bedoeld voor een omschrijving, mit eens beperkte. Dan zet je 't dus maar in de comments of een aparte file.

[Multispeed]

even ter info

jullie hebben allemaal gelijk maarja als een complete afdeling zegt
"wij hebben het altijd zo gedaan"
de directeur die het zo wil
en mijn baas die het aan mij vraagt

tjah....


ik loop al maanden te zeggen doe gewoon windows sharen en helemaal geen speciale tekens ben je van het gezeik af maar dat is dus geen optie.

ik ben btw bezig met de naam van dat pakket wat ik gevonden had post ik zo nog wel ff

[OzBoz]

Hydraulik-Phunk schreef op vrijdag 17 december 2004 @ 13:06:
Dan de hamvraag; wie gebruikt er nu filenames als "klant a en klant b voor klant c via d die wil rood / wit iplv blauw / geel.html" ????

Sorry hoor, maar ik zou eerder naar de oorzaak van je probleem kijken dan 't gevolg van een kromme oplossing.
Als je nu gewoon 'professionele' bestandnamen gebruikt en een beschrijvingsfile in tekstformaat er bij legt lijkt mij dat de problemen de wereld uit zijn.
Die lange bestandnamen mogen wel werken onder Windows, maar ook dan kan je nog tegen rare problemen oplopen is mijn ervaring.

Een bestandsnaam is niet bedoeld voor een omschrijving, mit eens beperkte. Dan zet je 't dus maar in de comments of een aparte file.

Nou hier in de studio [OS9] hebben ze jarenlang (en nog volgens mij) 1234-231/Omschrijving gebruikt als bestands namen. Dat is niet intelligent, maar zo heten ze nu dus wel. Binnenkort gaat de studio echter nokken dus wil ik proberen meteen HD-wise alle / te vervangen door wat anders.

Een bestandsnaam die ook het document omschrijft is trouwens wel noodzaak in werkomgeving. In principe is een ordernummer voldoende, maar het kan erg fijn zijn te zoeken op logische namen ipv bijvoorbeeld iets als 'achterkant.eps'. Maar goed, als ik studiomanager was geweest had ik me daar drukker om gemaakt. Desnoods met lijfstraffen dreigen

[Multispeed]

Woon je in de buurt van ermelo ??

dan mag je het ff voordoen

OzBoz schreef op vrijdag 17 december 2004 @ 13:50:
[...]


Nou hier in de studio [OS9] hebben ze jarenlang (en nog volgens mij) 1234-231/Omschrijving gebruikt als bestands namen. Dat is niet intelligent, maar zo heten ze nu dus wel. Binnenkort gaat de studio echter nokken dus wil ik proberen meteen HD-wise alle / te vervangen door wat anders.

Een bestandsnaam die ook het document omschrijft is trouwens wel noodzaak in werkomgeving. In principe is een ordernummer voldoende, maar het kan erg fijn zijn te zoeken op logische namen ipv bijvoorbeeld iets als 'achterkant.eps'. Maar goed, als ik studiomanager was geweest had ik me daar drukker om gemaakt. Desnoods met lijfstraffen dreigen

[Hydraulik-Phunk]

achterkant.eps is prima.

Zo lang je je werkmappen overzichtelijk houdt zijn dat soort bestandsnamen geen probleem.
Maar bestandsnamen als 'achterkant z.logo cmyk 300 dpi/jansen order 19-03-05.eps' daar zal je problemen mee krijgen, vooral in het afrondingstadium.

Een goede mapstructuur en doordachte werkwijze die door iedereen wordt gehandhaaft is cruciaal. Ook al gaat het misschien ook wel goed op de 'oude' wijze

[Multispeed]

jep zo had ik het ook gedaan maarja

extern sys. beheer he niks te vertellen

[leon1e]

Gouldian schreef op vrijdag 17 december 2004 @ 14:01:
jep zo had ik het ook gedaan maarja

extern sys. beheer he niks te vertellen

Dat is echt pure onzin, als jij die klant een voorstel geeft van hoe het beter kan en waarom het zo moet dan is elke klant bereid om te luisteren. Maar als jij net zoals in dit topic aan komt schreeuwen, met eigenlijk moet het windows sharing worden (smb/cifs) dan luisteren de mensen echt niet nee. Zeker niet de mensen met een apple tik, want windows is eng.

Ga je dus eerst eens verdiepen in de protocollen voordat je hier loopt te blaten.

[OzBoz]

Gouldian schreef op vrijdag 17 december 2004 @ 13:55:
Woon je in de buurt van ermelo ??
dan mag je het ff voordoen

Sorry, Deventer Maar het is eigenlijk gewoon super belangrijk om goed met en bestanden om te gaan. Zeker gezien de hoeveelheid data binnen bedrijf. Hier werken we met een aparte HD voor zeg maar de opmaak bestanden en een HD voor de beelden. Dat is misschien niet heel praktisch maar is wel handiger met backup/archiveren. De documentserver wordt zeg maar nooit leeggemaak (vreet niet zoveel ruimte) en beeldbank moet wel gezien de hoeveelheid data.

Maar hoe je ook werkt, als iedereen maar volgens het zelfde systeem werkt. Consequent. En wat betreft speciale tekens, daar moet je gewoon eigenlijk instructies voor uitdelen. Hoe vaak ik wel niet geroepen wordt omdat cd op pc niet werkt (door fijne slash)..

[Multispeed]

Het gaat dus om Mac Server Ip
http://cyansoftware.com/download_MacServerIP.htm

maar zoals al gezegt dat is een beta kent iemand een vergelijkbaar protocol die geen beta meer is .

[leon1e]

Mac Server ip praat gewoon APL (Apple Talk), met uitzondering van "MacServerIP 9.0 Cluster" is alles uit de beta. Of ga je het draaien in een cluster omgeving?

[usr-local-dick]

jullie hebben allemaal gelijk maarja als een complete afdeling zegt
"wij hebben het altijd zo gedaan"
de directeur die het zo wil
en mijn baas die het aan mij vraagt

tjah....

Je baas vraagt het. Op een vraag zijn twee antwoorden mogelijk: ja en nee.
In jouw geval is het nee.
Het kan niet. Klaar.

[Multispeed]

Maar waarom kan die het dan wel ??

als het gewoon APL praat

leon1e schreef op vrijdag 17 december 2004 @ 15:19:
Mac Server ip praat gewoon APL (Apple Talk), met uitzondering van "MacServerIP 9.0 Cluster" is alles uit de beta. Of ga je het draaien in een cluster omgeving?

[leon1e]

Gouldian schreef op dinsdag 21 december 2004 @ 09:27:
Maar waarom kan die het dan wel ??

als het gewoon APL praat

[...]

Even google'en op AFP 3.1 doet echt wonderen:

Apple Filing Protocol (AFP) 3.1 is required to provide full server compatibility with Mac OS X clients, and works as well with Mac OS 8/9 clients. EtherShare support for AFP 3.1 brings these major benefits to OS X clients:

- Very large file support, no 4 GB limit any longer, for archive, prepress and video data
- Unicode/UTF-8 file names and volumes
- File names up to 255 characters in length
- Client/Server reconnect support, and client sleep support
- 2-3 times faster performance than NFS or SMB/CIFS file sharing
- Smart file/folder permissions for OS X clients

File services for macintosh gebruikt nog een ouder protocol. Ik heb verde in dit topic echt 0,0 eigen inzet van je gezien, waarschijnlijk is het verstandig als je in het vervolg zelf ook even zoekt .

[chem]

Hey Gouldian...

ik heb je al de kans gegeven om een beter topic te beginnen. Ook dat doe je zonder echte inzet, en nu wil je nog met het handje meegeholpen worden.

En daar zijn wij niet voor.