[Red Hat 9] Extended ASCII in filenames :/

[NoBody]

Weer eens een topic van mij

Het zit zo; op mijn huidige stageplek staat momenteel een Windows 2000 Server, die bepaalde functionaliteiten biedt, o.a. file- en webserver.

Nou is het mijn stageopdracht om een Red Hat 9 server te bouwen met dezelfde funtionaliteit, tot dusver geen problemen, in principe draait al het nodige er op...
Nu loop ik tegen 1 probleem aan; een aantal bestanden op de huidige Win2k fileserver bevatten extended ASCII tekens, dus tekens zoals ™ of … (die laatste zijn geen 3 stippen, maar ASCII code 0133, zie hier voor overzicht)... leuk dat Windows dat allemaal maar toestaat, maar nu moeten er bestanden gekopiëerd worden van de huidige fileserver naar de nieuwe, uiteraard al even de betreffende share gemount met mount -t smbfs //server/e /data -o username= ,password= ,codepage=cp850,iocharset=iso8859-15 en daarna aan het kopiëren geslagen, het spul gaat van een smbfs mount naar een aparte FAT32 partitie.

Jullie zullen ondertussen wellicht al aanvoelen wat het probleem is, de linux bak herkent deze files dus niet goed op de server, voorbeeld:
bestandsnaam op de Win2k server: dit_is_een_lange_bestandsnaam­™.htm, linux maakt er dit van: dit_is_een_lange_bestandsnaamT.htm

Nou zou ik hier normaalgesproken niet zo moeilijk over doen, ware het niet dat hij, wanneer ik iets met deze file probeer te doen vanaf de linux bak, hij zegt dat het bestand niet bestaat

Nadien letterlijk uren aan het zoeken geweest op zowel Google (zoekwoorden; alle mogelijke combinaties van de woorden "linux", "extended ascii", "filename" en een aantal varianten daarop), hetzelfde op GoT gedaan en uiteindelijk ook nog even de beide FAQ's van Non-Windows Operated Systems doorgespit. Verder had mijn baas nog een paar hele dikke pillen van Red Hat (handleidingen) liggen, waar ik even snel doorheen gebladerd heb (aan de hand van de inhoud, anders was ik nu nog bezig geweest ).

Verder ook zelf nog een aardige poos zitten prutsen met language settings, lettertypen, andere TERMs (vt110, vt220, linux, linux-redhat, xterm, xterm-color)

Nog even een aantal zaken die wellicht belangrijk zijn voor het oplossen van dit probleem:

Output commando "export" (overbodige variabelen weggelaten):

declare -x BASH_ENV="/root/.bashrc"
declare -x G_BROKEN_FILENAMES="1"
declare -x HISTSIZE="1000"
declare -x INPUTRC="/etc/inputrc"
declare -x LANG="nl_US"
declare -x LESSOPEN="|/usr/bin/lesspipe.sh %s"
declare -x SHELL="/bin/bash"
declare -x SHLVL="1"
declare -x TERM="linux"

/etc/sysconfig/i18n:

LANG="nl_US"
SUPPORTED="nl_NL.UTF-8:nl_NL:nl:en_GB.UTF-8:en_GB:en:en_US.UTF-8:en_US:en"
SYSFONT="latarcyrheb-sun16"

LANG="nl_US@euro" ook geprobeerd, maar dit had helaas geen enkel effect

Verder ook handig om erbij te zeggen dat dit dus compleet buiten X is, dus geen konsole oid, pure shell (momenteel SSH omdat ik nu thuis zit)

In KDE doet hetzelfde probleem zich overigens voor, zowel in Nautilus als Konsole.

Om het allemaal in één regel samen te vatten: Red Hat 9 weigert bestandsnamen met extended ASCII karakters te herkennen en geeft aan dat het bestand niet zou bestaan wanneer ik er iets mee wil doen (kopiëren/moven bijvoorbeeld).

Alvast bedankt

[ Voor 15% gewijzigd door NoBody op 08-12-2003 21:20 ]

[Zwerver]

* Zwerver denkt aan quotejes....

maw als je dr quotes omheen zet leest ie ze dan niet goed? Zoja dan had je deze kunnen vinden met google, zo nee, kan je niet gewoon een hele dir te moven?

[pinball]

Ondersteund fat32 die tekens wel? Dwz: wat gebeurt er als je ze naar een windows machine met fat32 kopieert?

Heb je al eens geprobeerd samba te omzeilen? Bijvoorbeeld door met scp (via ssh dus) bestanden van de windows machine naar de linux machine kopieren?

[ajvdvegt]

Ik heb het ook even geprobeerd, maar onder X is het geen probleem om bestanden met die extended acsii tekens aan te maken of te bewerken. Ook in een terminal geeft het geen problemen.
Zonder X gaat het iets minder goed inderdaad. De karakters zijn opeens verdwenen. Ik kan ze dus wel verplaatsen of kopieeren (met behoud van vreemde tekens), maar de hele console werkt alsof die karakters niet bestaan.

Ik heb geen Windows computer in de buurt, maar ik zie niet in waarom het via samba niet zou werken.

Even een screenshotje (van de console gaat wat lastig helaas ), en wat specs:
Debian unstable
Kernel 2.6.0test10
Gnome 2.4
XFree 4.3.0-0pre1v4
XFS (bestandsysteem)

[wizl]

code:

man 5 smb.conf

en dan ff. zoeken naar 'character set', en 'valid chars'
daarmee zou het moeten lukken

[edit] en ik moet leren lezen je hebt de bestanden dus al naar je linux fs gekopieerd . . .

[ Voor 70% gewijzigd door wizl op 08-12-2003 22:07 ]

[NoBody]

Zwerver: Quotes mochten ook niet baten helaas...

Pinball: of FAT32 het ondersteunt, volgens mij wel.. maar dat is niet het punt, want zover kom ik dus niet eens, hij herkent ze dus al niet goed in zowel KDE als bash/tty

ajvdvegt: ik kan verder onder KDE ook gewoon files met de vreemdste tekens aanmaken, bewerken, verwijderen enz. enz.

wizl: er is in principe geen sprake van een linux FS, want de transfers gaan gelijk van smbfs naar FAT32, overigens ga ik dat nog wel even doen wat je zei
Update: smb.conf is dus puur voor de samba server, niet voor de cliënt. Je kan wel een aantal dingen instellen die, als dit voor de smbclient was geweest, waarschijnlijk ook de oplossing waren geweest

Tot slot; wanneer ik op één van de Win98 werkstations naar de betreffende share navigeer, staat er zo'n leuk overeindstaand rechthoekje, welke aangeeft dat ook Win98 niet weet wat het is... maar die laat het tenminste sortof in "raw" zien, zodat je die wel gewoon kunt bewerken/editten/kopiëren

In ieder geval bedankt voor de reacties tot dusver, ik hoop dat de gouden reactie nog komt

Update: ik denk dat ik, in overleg met mijn baas, de tijdelijke omweg die door Pinball werd genoemd, wellicht ga proberen... maar hiermee is het probleem natuurlijk niet opgelost

[ Voor 47% gewijzigd door NoBody op 09-12-2003 09:58 ]

[NoBody]

Terwijl de files worden overgepompt via SCP/SSH (heb hem zijn gang laten gaan toen ik vanmiddag naar huis ging, zal nu wel zo ongeveer klaar zijn als hij niet tegen errors is aangelopen), vermoed ik dat het toch tussen de Windows- en Linux-server zit, dat het SMB-protocol het niet goed ondersteunt of iets dergelijks

Verder nog iemand ideeën

[pinball]

Gebruik je samba 3 al? Misschien werkt het daar wel mee? Zo ja, heb je het probleem ook met samba 2?

Als die bestanden eenmaal op de RH machine staan, hebben de clients dan ook het probleem als ze die machine via samba benaderen?
Als dat niet zo is zou je de communicatie tussen win2k en RH9 ook om kunnen draaien: laat de win2k server een 'net use' doen naar een samba share. Of installeer UNIX services voor 2k, en laat die RH9 machine daar naar connecten.

En anders is het denk ik tijd om de samba mailing list met een bezoekje te vereren

[NoBody]

Pinball schreef op 09 december 2003 @ 22:43:
Gebruik je samba 3 al? Misschien werkt het daar wel mee? Zo ja, heb je het probleem ook met samba 2?

Als die bestanden eenmaal op de RH machine staan, hebben de clients dan ook het probleem als ze die machine via samba benaderen?
Als dat niet zo is zou je de communicatie tussen win2k en RH9 ook om kunnen draaien: laat de win2k server een 'net use' doen naar een samba share. Of installeer UNIX services voor 2k, en laat die RH9 machine daar naar connecten.

En anders is het denk ik tijd om de samba mailing list met een bezoekje te vereren

Version 2.2.7a-security-rollup-fix draait er op, zomaar even updaten naar 3 zit er niet in (tenminste niet onder het mom "laten we dat even proberen"), ze willen zien dat ik weet wat ik doe en wat dat evt. voor andere gevolgen kan hebben, dus een upgrade vermijd ik het liefst zoveel mogelijk, en nu dat de bestanden via SCP overgeheveld zijn (tenminste, ik ga er dus vanuit dat daar geen fouten bij ontstaan zijn... maar dat zie ik pas morgen ) heeft het oplossen van dit probleem ook niet meer zo'n haast, maar natuurlijk wil ik, na A gezegd te hebben (door dit topic te openen), ook B zeggen, ook als dat uiteindelijk toch een upgrade betekent

Persoonlijk heb ik het gevoel dat ik later bij wijze van spreken een end weg kan spelen met extended ASCII karakters in bestanden/directory's, wanneer de files achter de al klaarstaande Samba-server staan ipv achter de Win2k machine...

[MSalters]

Het probleem is dat NT geen extended ASCII oid gebruikt (er zijn meer dan 15 extensies, welke bedoel je?). NT gebruikt Unicode, en om precies te zijn, Unicode versie 3.0. Dat zou al moetn helpen bij het googlen. De volgende vraag is wat de NT server er mee doet, dat is dus een WOS vraagje: hoe gaat SMB onder Windows om met Unicode file names?
Ik vond op google bij de eeste hit al links naar samba.org, waarin staat dat Unicode names onderhandeld moeten worden tussen server en client. De release notes van Samba 3, puntje 2 is

2) Unicode support. Samba will now negotiate UNICODE on the wire
and internally there is now a much better infrastructure for
multi-byte and UNICODE character sets.

Out of luck

De gemene instinker daarna is, hoe ga je NT streams binnen een file kopieren? NT streams zijn files binnen files, bv test.txt:Stream. NT gooit die dingen normaal gesproken weg als je files van een NT bak af kopieert.

PS. 12 regels onder "Unicode support:" staat

15) Improvement of ACL mapping features based on code donated by Andreas GrÃŒnbacher.

Misschien nog niet 100% Unicode

[Verwijderd]

NoBody schreef op 09 december 2003 @ 23:07:
[...]

Version 2.2.7a-security-rollup-fix draait er op, zomaar even updaten naar 3 zit er niet in (tenminste niet onder het mom "laten we dat even proberen"), ze willen zien dat ik weet wat ik doe en wat dat evt. voor andere gevolgen kan hebben, dus een upgrade vermijd ik het liefst zoveel mogelijk, en nu dat de bestanden via SCP overgeheveld zijn (tenminste, ik ga er dus vanuit dat daar geen fouten bij ontstaan zijn... maar dat zie ik pas morgen )

De code page die gebruikt wordt om © (U+009A) en ™ (U+2122) af te beelden is 1252 en wordt vreemd genoeg niet door Samba ondersteund. Er wordt conversie verricht om bestanden wel met een ISO8859-1 naam op te kunnen slaan en daarom worden tekens als © naar c geconverteerd.

Versie 3 is zeker het proberen waard omdat deze versie Unicode ondersteund in tegenstelling tot alle voorgaande versies. Unicode zou al deze problemen moeten verhelpen.

Advies is om een testmachine daarnaast te draaien, waarmee je kan experimenteren. Het is een mooie uitbreiding op je stageverslag ;-p

[Jimbolino]

als ik me niet vergis kunnen ascii karakters gewoon als escape karakters geschreven worden?
bv "filename\205"

of zeg ik nu iets heel doms wat er niks mee te maken heeft?

[ Voor 14% gewijzigd door Jimbolino op 09-12-2003 23:53 ]

[Wilke]

Jimbolino schreef op 09 december 2003 @ 23:53:
als ik me niet vergis kunnen ascii karakters gewoon als escape karakters geschreven worden?

Ja, maar daar heb je niet zo veel aan als Samba vervolgens bij het kopieeren dat weer (verkeerd/onterecht) converteert of whatever.

of zeg ik nu iets heel doms

Dat niet,

wat er niks mee te maken heeft?

Dat wel

[NoBody]

MSalters schreef op 09 december 2003 @ 23:40:
Het probleem is dat NT geen extended ASCII oid gebruikt (er zijn meer dan 15 extensies, welke bedoel je?)

Nou ik ben niet zo heel erg into ASCII/Codepages en wat wat precies is... dus onder welke extensies genoemde tekens vallen zou ik zo niet weten

NT gebruikt Unicode, en om precies te zijn, Unicode versie 3.0. Dat zou al moetn helpen bij het googlen. De volgende vraag is wat de NT server er mee doet, dat is dus een WOS vraagje: hoe gaat SMB onder Windows om met Unicode file names?
Ik vond op google bij de eeste hit al links naar samba.org, waarin staat dat Unicode names onderhandeld moeten worden tussen server en client. De release notes van Samba 3, puntje 2 is
[...]

Out of luck

Nou het rare is dus dat wanneer je er met een Windows 98 machine heen browset (naar de betreffende files op de Win2k Server), dat die de betreffende tekens weergeeft als zo'n volzwart rechthoekje, wat mij vertelt dat Windows 98 die tekens niet kan weergeven, maar de ASCII code wel herkent, dus wat dat betreft zou je zeggen dat Windows' eigen SMB server het gewoon ondersteunt en dat het hem dus ergens in de cliënt zit (Samba 2.2.7) en dat is de reden dat ik dit topic in Non-Windows Operated Systems heb gepost ipv Windows Operated Systems

De gemene instinker daarna is, hoe ga je NT streams binnen een file kopieren? NT streams zijn files binnen files, bv test.txt:Stream. NT gooit die dingen normaal gesproken weg als je files van een NT bak af kopieert.

Ik geloof niet dat er hier gebruik wordt gemaakt van NT streams (of ik begrijp je niet goed, maar daar zal ik nog wel even over Google'n ).

Ik denk, ook na KuRMiE's reactie, niet dat ik om een upgrade naar Samba 3 heen kan (ook i.v.m. het probleem die ik noemde in " Krijg SAMBA met users niet werkend "), ik zal het eens aan de kaak stellen vandaag

Tot zover in ieder geval bedankt luitjes

[NoBody]

*schop*

Samba3 lost het probleem in ieder geval niet op, maar als server kunnen Windows machines er wel gewoon de raarste bestanden (kwa naam) naartoe sturen en ook weer afhalen (zowel Samba2 als 3), ik denk dat dat voorlopig voldoende is. Een echte oplossing voor het communicatieprobleem tussen Linux <-> Win2k Server is schijnbaar een bitch om te vinden

In ieder geval wilde ik dit nog even kwijt, omdat ik altijd mijn topics af wil sluiten zodat men weet hoe het nou eigenlijk afgelopen is (iets wat ik helaas bij andere topics vaak mis ).

Bedankt tot zo ver allemaal, mochten er toch nog hints/tips zijn dan kun je uiteraard nog reply'en

[DDX]

smbclient is zoiezo beetje vreemd
standaard ook geen support voor files groter dan 2GB nml

kwam ik tijdje geleden achter toen ik aantal dvd images aan het moven was van windows machine -> linux bak (via smbclient mount)
leuk als je dan achteraf files tegenkomt van 200 a 300mb

moest je dus kernel + smbclient voor patchen


ik zit trouwens net wat te lezen over kernel 2.6 :

http://www.kniggit.net/wwol26.html

In addition to improving support for the UNIX-style network filesystems, Linux 2.6 also delivers many improvements to Windows-style network filesystems. The standard shared filesystem for Windows servers (as well as OS/2 and other operating systems) has been the SMB ("server message block") protocol and the Linux kernel has had excellent client support of the SMB protocol for many revisions. Windows 2000 however standardized on an upgraded superset of the SMB protocol, known as CIFS ("common internet filesystem.") The intention of this major update was to streamline and refine certain aspects of SMB which had at that point become a complete mess. (The protocol itself was loosely defined and often extended to the point that there were cases even where the Win95/98/ ME version was incompatible with the WinNT/Win2k version.) CIFS delivered on that intention and added UNICODE support, improved file locking, hard linking, eliminated the last vestiges of NetBIOS dependencies, and added a few other features for Windows users.[/ME] Since Linux users do not like to be kept in the dark for long, Linux 2.6 now includes completely rewritten support for mounting CIFS filesystems natively. Linux 2.6 also now includes support for the SMB-UNIX extensions to the SMB and CIFS protocols which allows Linux to access non-Windows file types (such as device nodes and symbolic links) on SMB servers which support it (such as Samba.) Although not as commonly seen today, Linux has not completely forgotten about the Novell NetWare users. Linux 2.6 now allows Linux clients to mount up to the maximum of 256 shares on a single NetWare volume using its built in NCP ("NetWare Core Protocol") filesystem driver.

[ Voor 2% gewijzigd door DDX op 18-12-2003 10:54 . Reden: grr lekker dat / ME in quote ;) ]