[C#] Files inlezen

[Verwijderd]

Ik ben bezig met iets om een filetje in te lezen, en daarna mee te werken. Dat lukt allemaal wel, maar als een ander programma het gebruikt kan dat niet. Nou zou ik graag willen dat hij hem dan gewoon alleen inleest.

FileStream file = new FileStream(folderName, FileMode.OpenOrCreate,FileAccess.Read);


Hij vind wel precies de goeie file, dat heb ik gechecked alleen hij is in gebruik. En wil het programma wat het filetje gebruikt gewoon aan kunnen laten staan. Heeft iemand een idee?

[NMe]

Is het niet zo dat een filestream open blijft staan tot jij hem sluit? Ik heb geen ervaring met C# maar wel met klassiek C, en daar kun je gewoon de file in een keer inlezen (fopen en fread e.d.) en daarna sluiten. Daarbij heb ik er nooit last van gehad als een ander programma die file toevallig open had.

[whoami]

Door welke applicatie wordt die file gebruikt? Door een applicatie die je zelf geschreven hebt (in C#)?
Dan moet je in die applicatie aangeven, dat die file ook door andere app's mag gelezen worden.

code:

new FileStream (path, ..., ..., FileShare.Read);

[Verwijderd]

Nee, niet door een eigen programma. Gewoon door een programma, net zoals msn, dat op de achtergrond altijd blijft draaien.


En ik wil de config gewoon inlezen.

Maar ik dacht dat het altijd wel kon een file readonly inlezen. Of heb ik dat fout ?


In notepad kan ik de file wel gewoon openen.

[ Voor 10% gewijzigd door Verwijderd op 15-06-2004 10:56 . Reden: Iets getest :) ]

[gorgi_19]

Verwijderd schreef op 15 juni 2004 @ 10:54:
Maar ik dacht dat het altijd wel kon een file readonly inlezen. Of heb ik dat fout ?

Afaik heb je dat fout.

[whoami]

Dat zal ervanaf hangen hoe die file gelocked is.

[Verwijderd]

Maar er is niet iets waardoor je zoiets kan omzeilen ?

behalve de applicatie te sluiten ?

[curry684]

Verwijderd schreef op 15 juni 2004 @ 10:59:
Maar er is niet iets waardoor je zoiets kan omzeilen ?

behalve de applicatie te sluiten ?

Beetje vragen naar de bekende weg he?

Win32 definieert niet voor niets sharing modes. Als een programma een file lockt voor writing zonder sharing, zal ie dat wel met goede reden doen: namelijk dat ie niet wil dat er iemand data gaat lezen terwijl hij nog niet expliciet klaar is. Ergo, zolang hij niet bereid is te sharen kom je er niet tussen, en een 'manier om te omzeilen' zou een bug in Windows zijn. En helaasch, een op dat punt zou binnen een dag gepatched zijn want het zou een hopeloze compromittering van systeemstabiliteit zijn (je mag dan plots op runtime ntoskrnl.exe, kernel32.dll en zo gaan overschrijven )

[bigbeng]

curry684 schreef op 15 juni 2004 @ 11:12:
[...]
...

En helaasch, een op dat punt zou binnen een dag gepatched zijn want het zou een hopeloze compromittering van systeemstabiliteit zijn (je mag dan plots op runtime ntoskrnl.exe, kernel32.dll en zo gaan overschrijven )

Je maakt het wel erg verwarrend vind ik, hoor. Het voorbeeld waar je mee begint gaat over het lezen van een gelockt bestand en je eindigt met het overschrijven van een gelockt bestand. Lijkt me toch dat daar een essentieel verschil in zit.

@TS: De meeste programma's die een bestand openen, doen dit meestal shared, zodat het voor lezen beschikbaar blijft. Maar dit is natuurlijk geen garantie, je zult dus een oplossing voor die situatie moeten verzinnen.

[Verwijderd]

Mmm, ja owkee, maar ik wou het alleen inlezen, en na wat zoeken vond ik deze methode en die werkt wel

code:

        StreamReader objReader = new StreamReader(folderName);
                string sLine="";
                ArrayList arrText = new ArrayList();

                while (sLine != null)
                {
                    sLine = objReader.ReadLine();
                    if (sLine != null)
                        arrText.Add(sLine);
                }
                objReader.Close();

[curry684]

bigbeng schreef op 15 juni 2004 @ 11:46:
[...]


Je maakt het wel erg verwarrend vind ik, hoor. Het voorbeeld waar je mee begint gaat over het lezen van een gelockt bestand en je eindigt met het overschrijven van een gelockt bestand. Lijkt me toch dat daar een essentieel verschil in zit.

Nee hoor, allemaal kwestie van deze 3 flags van CreateFile(...):

Value	Meaning
FILE_SHARE_DELETE	Enables subsequent open operations on the object to request delete access. Otherwise, other processes cannot open the object if they request delete access. If the object has already been opened with delete access, the sharing mode must include this flag. Windows Me/98/95:  This flag is not supported.
FILE_SHARE_READ	Enables subsequent open operations on the object to request read access. Otherwise, other processes cannot open the object if they request read access. If the object has already been opened with read access, the sharing mode must include this flag.
FILE_SHARE_WRITE	Enables subsequent open operations on the object to request write access. Otherwise, other processes cannot open the object if they request write access. If the object has already been opened with write access, the sharing mode must include this flag.

Gezien het feit dat het Langedaik nu wel lukt denk ik dat ie over de laatste alinea van deze omschrijvingen viel: als een ander proces wel shared access toestaat, maar zelf vraag je er niet om krijg je het ook niet, je kunt geen exclusive xs krijgen terwijl iemand er al op bezig is.