[UNIX] Niet case sensitive maken van filesystem of mappen?

[FastBunny]

Voor mijn werk zijn we sinds kort onze applicatie aan het porten naar een webversie via Oracle Application Server. De installatie van de database werd altijd via een Windows Client gedaan, daarin worden vele (lees: 20.000) scripts aangeroepen aangelang welke actie er nodig is.

Nu zijn we dit aan het porten naar een Unix Applicion server en proberen we van daaruit de installatie van de database te doen, echter hier gaat het fout. Omdat er in het verleden nooit rekening is gehouden met Unix zijn alle bestandnamen willekeurig qua hoofd/kleine-lettergebruik.

Via wat rename tools kan ik alles naar 1 standaard zetten dat is geen probleem, echter in de script wordt vaak weer direct naar een ander script verwezen via een de naam welke weer willekeurig is qua benaming. Nu is het bijna ombegonnen werk om alle scipts handmatig na te lopen om hier alles te controlleren.

Het zou een uitkomt zijn als het mogelijk zou zijn om 1 directory op een UNIX server (in dit geval Sun Solaris 5.9) niet case-sensitive te maken. Ik heb al wat gezocht op internet maar overal staat dat *nix case-sensitve is maar nergens wordt er gesproken over een mogelijke work-arround. Zijn die er of is wat ik wil simpel weg niet mogelijk.

[Xiphalon]

Samba installeren, en je eigen bestandssysteem door samba heen mounten. Samba heeft een optie om case-insensitief te worden.

[Verwijderd]

Andere optie is dat je met wat slimme sed acties gewoon al je scripts langsloopt en alles op 1 standaard zet. Hiermee voorkom je ook nog eens een performance hit die je krijgt als je een laag als samba bovenop je filesystem zet.

[MBV]

je kan een find-and-replace door alle bestanden heen laten lopen, zijn waarschijnlijk veel tools die batch-acties ondersteunen. Je kan dan zoeken naar een patroon, en omzetten naar kleine letters.
Bij php-bestanden: include("./Blaat/included.php");
- zoek naar de string ".php"
- selecteer de tekst ervoor tot aan ", en erna tot aan "
- zet het om naar lowercase

En ik heb geen zin om daar een ereg string voor te verzinnen, doe je zelf maar

[usr-local-dick]

Voor Linux is er een LUFS, daar kun case insensitive filesystemen mee mounten.
HElaas niet voor andere UNIXen zo tezien:

http://lufs.sourceforge.net/lufs/

[JaQ]

FastBunny schreef op 20 oktober 2004 @ 10:52:
Voor mijn werk zijn we sinds kort onze applicatie aan het porten naar een webversie via Oracle Application Server. De installatie van de database werd altijd via een Windows Client gedaan, daarin worden vele (lees: 20.000) scripts aangeroepen aangelang welke actie er nodig is.

Je hebt het over de installatie van de database? Wat belet je om de database op windows te installeren, een full-export te maken en deze weer op solaris te importeren?

[erger mode]Dit is trouwens een zeeeeeeeeeer voorkomend probleem wat veel van die klote forms/designer ontwikkelaars veroorzaken... [/erger mode]

[usr-local-dick]

Als ik het goed begrijp is dit een zielige feature van WIndows (en MacOS9):
je kan wel mixed case gebruiken zodat je bv echt FiLe.TxT, FilE.txt kan aanmaken, je ziet ook echt de verschillen. Maar als ze samen in een map moeten zijn ze opeens weer gelijk
Das wel triest, iets laten zien en doen alsof het werkt maar als je het echt wilt gebruiken -> homaar het werkt toch niet :(

Heb zoiets gehad met een netatalk server op linux met OS9 clients, daar kan je vanaf de mac een PIC.jpg en pic.jpg op kopieeren en die stonden daar dan met zijn tweeen.
Echter als je die map terug ging kopieeren naar OS9 krijg je allemaal File Already Exists errors...

[FastBunny]

DrFrankenstoner schreef op 20 oktober 2004 @ 14:27:
[...]


Je hebt het over de installatie van de database? Wat belet je om de database op windows te installeren, een full-export te maken en deze weer op solaris te importeren?

[erger mode]Dit is trouwens een zeeeeeeeeeer voorkomend probleem wat veel van die klote forms/designer ontwikkelaars veroorzaken... [/erger mode]

Dit wordt ook gedaan voor de basis, daarna komen er upgrades via sql, op deze manier worden databases ook geupgrade naar nieuwe versies, aangezien er in elke nieuwe versie van onze software er ook zaken in de database moeten worden aangemaakt/veranderd.

En het is zeker een erger iets, het staat op zo veel plaatsen fout vandaar dat ik op zoek ben naar een manier om dit te omzeilen, zoeken gaat lastig omdat er ook veel met variabledirectorynamen gewerkt wordt, en de extentie wisselend is .pb, .ps, .tmp, .log, .plb etc etc etc.

[blaataaps]

usr-local-dick schreef op 20 oktober 2004 @ 14:36:
Als ik het goed begrijp is dit een zielige feature van WIndows (en MacOS9):
je kan wel mixed case gebruiken zodat je bv echt FiLe.TxT, FilE.txt kan aanmaken, je ziet ook echt de verschillen. Maar als ze samen in een map moeten zijn ze opeens weer gelijk
Das wel triest, iets laten zien en doen alsof het werkt maar als je het echt wilt gebruiken -> homaar het werkt toch niet :(

Dat heeft weinig met triest te maken, er is gewoon een verschil tussen case-aware, case-sensitive en case-insensitive, en het is algemeen bekend dat die filesystems case-aware zijn, maar niet case sensitive en heeft dus niks met "laten zien en doen of iets werkt" te maken.

[usr-local-dick]

Dat heeft weinig met triest te maken, er is gewoon een verschil tussen case-aware, case-sensitive en case-insensitive, en het is algemeen bekend dat die filesystems case-aware zijn, maar niet case sensitive en heeft dus niks met "laten zien en doen of iets werkt" te maken.

Voor de end-user is het wel triest. En de end-user is heilig.

[CyBeR]

usr-local-dick schreef op 20 oktober 2004 @ 14:36:
Als ik het goed begrijp is dit een zielige feature van WIndows (en MacOS9):
je kan wel mixed case gebruiken zodat je bv echt FiLe.TxT, FilE.txt kan aanmaken, je ziet ook echt de verschillen. Maar als ze samen in een map moeten zijn ze opeens weer gelijk
Das wel triest, iets laten zien en doen alsof het werkt maar als je het echt wilt gebruiken -> homaar het werkt toch niet :(

Heb zoiets gehad met een netatalk server op linux met OS9 clients, daar kan je vanaf de mac een PIC.jpg en pic.jpg op kopieeren en die stonden daar dan met zijn tweeen.
Echter als je die map terug ging kopieeren naar OS9 krijg je allemaal File Already Exists errors...

Mja, ik zal ook nooit zeggen dat case insensitivity handig is. Maar wees wel volledig: MacOS X kent ook UFS en verscheidene vormen van HFS, waaronder een case sensitive versie.

[tomato]

Tsja, het is niet echt een mooie oplossing, maar ik moest wel even aan FUSE denken. Je zou hiermee vrij simpel een wrapper over het 'echte' filesystem kunnen maken die een case insensitive filter toepast. Er is ook een Python binding voor FUSE.

Ik hoop voor je dat iemand met een beter idee komt, want de Samba oplossing (eerder in dit topic) is eigenlijk een nog groter omweg.

Het beste doe je het natuurlijk als je toch je applicatie aan weet te passen, zodat het gewoon werkt. Maar ik begrijp uit je verhaal dat dat (op dit moment) niet haalbaar is.

[FastBunny]

tomato schreef op 20 oktober 2004 @ 18:07:
Tsja, het is niet echt een mooie oplossing, maar ik moest wel even aan FUSE denken. Je zou hiermee vrij simpel een wrapper over het 'echte' filesystem kunnen maken die een case insensitive filter toepast. Er is ook een Python binding voor FUSE.

Ik hoop voor je dat iemand met een beter idee komt, want de Samba oplossing (eerder in dit topic) is eigenlijk een nog groter omweg.

Het beste doe je het natuurlijk als je toch je applicatie aan weet te passen, zodat het gewoon werkt. Maar ik begrijp uit je verhaal dat dat (op dit moment) niet haalbaar is.

Uiteindelijk zal alle code wel aangepast gaan moeten worden ben ik bang. Een wrapper is in ieder geval een mooie tijdelijke uitkomt om andere problemen aan het licht te krijgen. De voornaamste reden waarom ik het vraag is omdat op dit moment de port naar unix spaak loopt en ik dus nog niet weet in hoevere de code echt aangepast moet gaan worden.

Ik had al gedacht aan het feit alles te hernoemen en alle scripts in hoofdletters te laten maken door bv een textpad, echter is Oracle weer case-sensitive en kan ik de scripts niet automatisch laten aanpassen. Vanaf dit moment wordt er wel netjes opgelet hoe het met kleine en hoofdletters zit alleen zit er nog code in van 4 jaar terug, en daar zit juist het grote probleem.

De wrapper zal ik eens proberen al wordt eigenlijk overal over Linux gesproken en niet over Unix, hoop dat dat voor die tools niet uitmaakt.

En ik heb geen zin om 20.000 sql files door te spitten en aan te passen

[JaQ]

FastBunny schreef op 20 oktober 2004 @ 15:30:
[...]

Dit wordt ook gedaan voor de basis, daarna komen er upgrades via sql, op deze manier worden databases ook geupgrade naar nieuwe versies, aangezien er in elke nieuwe versie van onze software er ook zaken in de database moeten worden aangemaakt/veranderd.

En het is zeker een erger iets, het staat op zo veel plaatsen fout vandaar dat ik op zoek ben naar een manier om dit te omzeilen, zoeken gaat lastig omdat er ook veel met variabledirectorynamen gewerkt wordt, en de extentie wisselend is .pb, .ps, .tmp, .log, .plb etc etc etc.

Het gaat dus om meer dan alleen database spul, want upgrades van je database inhoud kan je net zo goed op windows doen. De database upgraden naar een nieuwe versie (b.v. van 8.1.7 naar 9.0.2 of zo) kan je doen voor de import. Als het verder om forms gaat: De niet gecompileerde forms bevatten tekst met verwijzingen (bijvoorbeeld naar libraries: pll / plx). Daar kan je sed, grep en awk prima op los laten (leert de ervaring). Deze forms moet je toch opnieuw compileren op solaris (dat is scriptbaar overigens).

Uiteraard zal ik hier niet werven en zo , maar misschien tijd om maar eens een goede Oracle club te bellen met ervaring met dit soort migratie trajectjen? (en dan bedoel ik niet Oracle support, want iedereen die een beetje ervaring heeft met Oracle weet dat die dudes daar over het algemeen geen geweldig hoog kennis niveau hebben....)

[FastBunny]

DrFrankenstoner schreef op 21 oktober 2004 @ 14:28:
[...]


Het gaat dus om meer dan alleen database spul, want upgrades van je database inhoud kan je net zo goed op windows doen. De database upgraden naar een nieuwe versie (b.v. van 8.1.7 naar 9.0.2 of zo) kan je doen voor de import. Als het verder om forms gaat: De niet gecompileerde forms bevatten tekst met verwijzingen (bijvoorbeeld naar libraries: pll / plx). Daar kan je sed, grep en awk prima op los laten (leert de ervaring). Deze forms moet je toch opnieuw compileren op solaris (dat is scriptbaar overigens).

Uiteraard zal ik hier niet werven en zo , maar misschien tijd om maar eens een goede Oracle club te bellen met ervaring met dit soort migratie trajectjen? (en dan bedoel ik niet Oracle support, want iedereen die een beetje ervaring heeft met Oracle weet dat die dudes daar over het algemeen geen geweldig hoog kennis niveau hebben....)

Was beetje ondedelijk over de upgrades.
Onze applicatie heeft versie nummers bv 3.0.1, 3.1.0 3.1.1 etc. Bij een kale installatie wordt er begonnen met een kale 2.9 en deze wordt geupgrade naar de laatste beschikbare versie. De applicatie en de database moeten dezelfde versie hebben. (Versienummer wordt ook in database opgeslagen).

Vandaar dat er steeds scripts lopen om hem van 2.9 naar 3.1.1 te brengen er worden vaak nieuwe functies toegevoegd welke ook in de database geinstalleerd moet worden.

Waarom deze constructie? De database software zelf staat hier los van en wordt niet vaak geupgrade. Dan is er maar 1 cd nodig voor nieuwe installaties en alle upgrade onafhankelijk welke versie (mits hoger dan 2.9 maar die versie is 4 jaar oud en ook daar zijn wel oplossingen voor.)