Tegengaan dat een applicatie een bestand overshrijft.

[Bollux]

Hallo allemaal,

Wij draaien een 2003 terminal server waar de klanten hun eigen schijf hebben waar iedereen zijn eigen installatie heeft van het programma.

Ik wil dit gaan veranderen door er een globale installatie van te maken, dwz één maal het programma installeren en vervolgens op hun eigen schijf alleen de database zetten.

In de root van het programma staat een ini bestand waar het pad naar de database in staat. Het probleem is, elke keer als een klant inlogt, word dat ini bestand overschreven met het pad van de database waar ze op dat moment mee inloggen.

Als ik zorg dat het ini bestand geen write rechten heeft, krijg ik errors(logisch).

Ik heb het in een test omgeving staan en ben er een beetje mee aan het spelen, heb ook al gekeken naar symlinks en hardlinks, maar volgens mij lost het dit voor mij niet op.

Iemand mischien een idee hoe ik dit evt kan oplossen? De makers van de applicatie zijn niet echt behulpzaam

Thanks!

[Verwijderd]

De template ergens neerzetten en met CMD een copy commando bij de start laten uitvoeren naar de eigenlijke locatie?

[netvor]

Wat ik een beetje mis, is of het noodzakelijk is dat elke gebruiker de locatie van zijn DB in die inifile schrijft. Kennelijk wel, want als het programma dit niet kan doen (bestand is read-only) krijg je foutmeldingen. Waarom wil je dan tegengaan dat het bestand gewijzigd wordt? Ik vind de titel van je topic een beetje tegenstrijdig met de inhoud van je post.

Je kan overigens ook een wrapper-script schrijven dat, zodra het programma wordt afgesloten, de oude inifile terugzet middels een eenvoudige copy.

Tot slot, symlinks en hardlinks bestaan AFAIK niet binnen de windows wereld, tenminste niet native (cygwin heeft bijvoorbeeld een workaround met .LNK files).

[Bollux]

Wat ik bedoel is, dat het pad in de Raam2.ini voor iedereen hetzelfde moet zijn bijv:
I:\DB\Database.ext

De Applicatie zet er een unc pad in, waardoor het voor de volgende gebruiker niet meer klopt.

Ik vraag alleen maar of iemand hier misschien wat voor weet, anders moet ik misschien toch weer met de programmeur contact op nemen.

Sym/Hardlinks heb je wel degelijk voor windows:
http://www.shell-shocked.org/article.php?id=284

[Question Mark]

Joshualoman schreef op woensdag 17 juni 2009 @ 10:25:
In de root van het programma staat een ini bestand waar het pad naar de database in staat. Het probleem is, elke keer als een klant inlogt, word dat ini bestand overschreven met het pad van de database waar ze op dat moment mee inloggen.

Baggerapplicatie dus...

Meest mooie oplossing is om de INI-file met instellingen, te vervangen door Reg-keys in HKCU. (zoals MS ook adviseerd en afdwingt met het "designed for Windows" programma. Op deze manier kan per user een eigen set met instellingen gedefineerd worden.

Mocht de applicatieleverancier niet mee willen werken, dan zou je eens kunnen proberen om een junctionpoint aan te maken naar %userprofile%\inifile. Ik weet alleen niet of een junction overweg kan met variabelen (netwerkshare kan sowieso niet).

Mocht dit werken, dan kan elke user een ini file op een lokatie in zijn userprofile krijgen.

[Bollux]

Inderdaad een baggerapplicatie, heb dus al geprobeerd te pushen dat ze het veranderen maar dat willen ze dan weer niet..

junctionpoint werkt niet, dat heb ik geprobeerd, dat kan alleen op dezelfde schijf en geen netwerkschijf zoals je al zegt!

Misschien toch nog maar een keer gaan bellen met die lui

Thanks in ieder geval

[Question Mark]

Joshualoman schreef op woensdag 17 juni 2009 @ 11:41:
Ijunctionpoint werkt niet, dat heb ik geprobeerd, dat kan alleen op dezelfde schijf en geen netwerkschijf zoals je al zegt!

Daarom meld ik ook dat deze naar %userprofile% moet verwijzen, die staat standaard op "c:\documents and settings\username". De C-schijf is toch echt wel een local disk

De vraag is even of een junction naar een variable gemaakt kan worden.

[Bollux]

Hmm helaas geen variable mogelijk!

[alt-92]

Applicatieprutsers schoppen zodat ze er wel een multi-user versie van leren maken.

Of, als ze die wel degelijk hebben, niet proberen voor een dubbeltje op de eerste rang te willen zitten maar een multi-user licentie aan (laten) schaffen.

Het zou namelijk ook zomaar kunnen dat die hardcoded AppPath dependency op de inifile typisch is voor een single user versie (die je nu hebt blijkbaar)

[ Voor 65% gewijzigd door alt-92 op 17-06-2009 20:12 ]

[Bollux]

Jup.. schoppen heb ik al geprobeerd maar die firma werkt niet echt mee..

Als er een multi-user licentie zou zijn, hadden we die allang aangeschaft.. maar helaas!

[elevator]

Is er toevallig ergens een pad wat verwijst naar die ini file? Een oplossing die vroeger veel gebruikt werd (met de zogenaamde Application Compatibility Scripts en de "rootdrive") is om de INI file altijd te laten verwijzen naar bijvoorbeeld W:\IniFile\, die W: is vervolgens een gesubstitute drive naar het users' profiel zodat iedere user toch zijn eigen ini file heeft zonder dat de applicatie er voor aangepast is.