Windows CMD.EXE en output redirection

[Verwijderd]

Mede Tweakers,

Voor een bepaald procedure wil ik vanuit meerdere command files die naast elkaar lopen de activiteiten loggen naar een (1) logfile.

Nu is CMD.EXE ietwat rigide als het gaat om output redirection naar een file die _net_ even in gebruik is door een ander proces.

De melding is "The process cannot access the file because it is being used by another process" hetgeen natuurlijk perfect te verklaren is uit het voorgaande.

Is er een manier om CMD.EXE wat _soepeler_ te maken? Bijvoorbeeld met instellingen voor timeout en/of retry? Welke alternatieven zijn er eventueel?

Thanks Aad Slingeland

[Tallguy]

Volgens de FAQ doen we elkaar altijd al de groeten en hoef je dat niet alsnog te doen. Zou ik dus maar weghalen voordat een mod langs komt

[alt-92]

Verwijderd schreef op vrijdag 25 januari 2008 @ 13:15:
Voor een bepaald procedure wil ik vanuit meerdere command files die naast elkaar lopen de activiteiten loggen naar een (1) logfile.

Nu is CMD.EXE ietwat rigide als het gaat om output redirection naar een file die _net_ even in gebruik is door een ander proces.
Is er een manier om CMD.EXE wat _soepeler_ te maken? Bijvoorbeeld met instellingen voor timeout en/of retry?

meerdere processen die dezelfde file wil gebruiken gaan hier sowieso tegenaan lopen - we hebben het dan niet eens over filelocks maar over datacorruptie die optreedt omdat een flat (text)logfile geen enkele ondersteuning heeft voor recordlocking en concurrent writes.

Welke alternatieven zijn er eventueel?

Losse logfiles, syslog, een heel ander implementatieplan?

Denk nog eens goed na wat je nou eigenlijk wil bereiken en wat de gevolgen kunnen zijn?

Kensei schreef op vrijdag 25 januari 2008 @ 13:16:
Volgens de FAQ doen we elkaar altijd al de groeten en hoef je dat niet alsnog te doen. Zou ik dus maar weghalen voordat een mod langs komt

Gebruik dan een TR in plaats van het hier te posten

[Verwijderd]

alt-92 schreef op vrijdag 25 januari 2008 @ 13:35:
[...]

Losse logfiles, syslog, een heel ander implementatieplan?

Ik ben bij mijn oorsponkelijke plan gebleven en heb een zlef maar een progje gemaakt. Deze schrijft een string naar een file maar is wel zo slim om, in geval van een open error, even te wachten en het dan nog een keer te proberen.

Een test met vier procedures in vier verschillende command processors en loggen naarv 1 file loopt prima.


Thanks voor het meedenken. Aad