[VB.NET] Controleren of bestand al in gebruik is

[Verwijderd]

Goeiemiddag,

Kan iemand mij misschien wat meer vertellen over het volgende ?
Ik heb een applicatie die in een temp map kijkt welke bestanden daar staan. Nu wil ik alle bestanden die niet geopend zijn door een gebruiker verwijderen.

Hoe kan ik in vb.net 2005 controleren of een bestand al in gebruik is ?
Ik kon op Got en Google weinig vinden. Mischien dat ik verkeerde zoektermen gebruik ?

Alvast bedankt.

[Kappie]

weet niet de precieze functies/codes maar je zou kunnen proberen het bestand exclusief te openen. lukt dat niet dan heeft of de gebruiker daar geen rechten toe of het is al geopend (in gebruik).

Nogmaals ik weet niet welke vb functie(s) daar ten grondslag ligt maar ik zou het in die hoek zoeken.

[Mastermind]

Gewoon alle bestanden bij langsgaan in een for-loop. Dan het betreffende bestand verwijderen binnen een try. Hij zal de bestanden die geopend zijn niet kunnen verwijderen. De fout die in dat geval ontstaat vang je op met een catch. De bestanden die niet geopend zijn zal hij wel verwijderen.

[Verwijderd]

Mastermind schreef op donderdag 17 augustus 2006 @ 17:24:
Gewoon alle bestanden bij langsgaan in een for-loop. Dan het betreffende bestand verwijderen binnen een try. Hij zal de bestanden die geopend zijn niet kunnen verwijderen. De fout die in dat geval ontstaat vang je op met een catch. De bestanden die niet geopend zijn zal hij wel verwijderen.

Dat werkt idd wel maar dat is niet echt een hele nette oplossing ook al ziet de gebruiker er niks van. Ik ga toch liever voor een andere oplossing.

[pjvandesande]

C#:

try
{
     new FileStream( "c:\\myfile.txt",  FileMode.Append, FileAccess.Write, FileShare.ReadWrite )
}
catch( UnauthorizedAccessException )
{
     // File is gelockt or niet genoeg rechten.
}

Even uit me hoofd en in C#.

[Gerco]

Verwijderd schreef op donderdag 17 augustus 2006 @ 17:26:
Dat werkt idd wel maar dat is niet echt een hele nette oplossing ook al ziet de gebruiker er niks van. Ik ga toch liever voor een andere oplossing.

Lijkt me persoonlijk de netste oplossing die er is. Je applicatie moet de bestanden verwijderen, dus probeert hij dat. Als er iets misgaat, rapporteert hij dat en gaat vrolijk verder.

Als je van tevoren checkt of het bestand in gebruik is, is er niemand die kan garanderen dat een applicatie dat bestand niet opent tussen het moment dat jij checkt en je het wilt verwijderen. Die eventuele Exception zul je toch moeten opvangen, dus waarom van tevoren die check doen.

Daarnaast zijn er meer redenen waardoor een bestand niet verwijderd kan worden dan "in gebruik zijn", het kan een readonly file zijn, hij kan op een onbereikbare netwerkschijf staan. Je gebruiker heeft er misschien geen rechten op en nog 100 andere redenen, wil je die allemaal gaan controleren?

[whoami]

questa schreef op donderdag 17 augustus 2006 @ 17:27:

C#:

try
{
     new FileStream( "c:\\myfile.txt",  FileMode.Append, FileAccess.Write, FileShare.ReadWrite )
}
catch( UnauthorizedAccessException )
{
     // File is gelockt or niet genoeg rechten.
}

Even uit me hoofd en in C#.

Mja, ik denk ook dat er geen andere oplossing is, alhoewel dit eigenlijk behoorlijk ranzig is vind ik. (En traag)

[Verwijderd]

Gerco schreef op donderdag 17 augustus 2006 @ 17:30:
[...]

Lijkt me persoonlijk de netste oplossing die er is. Je applicatie moet de bestanden verwijderen, dus probeert hij dat. Als er iets misgaat, rapporteert hij dat en gaat vrolijk verder.

Als je van tevoren checkt of het bestand in gebruik is, is er niemand die kan garanderen dat een applicatie dat bestand niet opent tussen het moment dat jij checkt en je het wilt verwijderen. Die eventuele Exception zul je toch moeten opvangen, dus waarom van tevoren die check doen.

Daarnaast zijn er meer redenen waardoor een bestand niet verwijderd kan worden dan "in gebruik zijn", het kan een readonly file zijn, hij kan op een onbereikbare netwerkschijf staan. Je gebruiker heeft er misschien geen rechten op en nog 100 andere redenen, wil je die allemaal gaan controleren?

Het bestand moet als het niet meer in gebruik is eerst worden geencrypt voordat het mag worden verwijderd. Even vergeten te melden. oeps.

Dus : als het bestand niet in gebruik is encrypten naar een andere map en verwijderen

[Gerco]

Verwijderd schreef op donderdag 17 augustus 2006 @ 17:43:
Dus : als het bestand niet in gebruik is encrypten naar een andere map en verwijderen

Wat is daar de bedoeling van? Gaat het erom dat het bestand niet meer leesbaar is nadat het is verwijderd (een shredder dus) of wil je die encrypted kopieën bewaren?

In het eerste geval kun je namelijk gewoon zoiets doen:

Visual Basic .NET:

Try
  ' Encrypt het bestand in-place (geen kopie maken dus)
  ' Verwijder bestand
Catch WhateverException
  ' Niet gelukt, log melding en ga verder
End Try

Overigens is niet gegarandeerd dat het bestand ook geencrypt word op de manier die jij wilt. Het is namelijk best mogelijk dat Windows andere diskblokken uitkiest om de nieuwe file content in op te slaan en de oude als ongebruikt te markeren. Sterker nog, dat lijkt me vrij waarschijnlijk aangezien NTFS met transacties werkt.

Als je geen shredder wilt maken, maar gewoon de bestanden encrypted wilt bewaren lijkt me dat niet zo'n probleem. Het lijkt me sterk dat je dan methodes nodig hebt die tegen raw disk access bestand zijn.

[ Voor 30% gewijzigd door Gerco op 17-08-2006 17:49 ]

[Mastermind]

Dan doe je in plaats van .Delete() .Move() en de directory met de gemovede bestanden encrypt je.

[Verwijderd]

Gerco schreef op donderdag 17 augustus 2006 @ 17:47:
[...]

Wat is daar de bedoeling van? Gaat het erom dat het bestand niet meer leesbaar is nadat het is verwijderd (een shredder dus) of wil je die encrypted kopieën bewaren?

In het eerste geval kun je namelijk gewoon zoiets doen:

Visual Basic .NET:

Try
  ' Encrypt het bestand in-place (geen kopie maken dus)
  ' Verwijder bestand
Catch WhateverException
  ' Niet gelukt, log melding en ga verder
End Try

Ik heb een applicatie waar word excel en pdf documenten aan hangen. Deze staan encrypted opgeslagen. als ik dubbelklik op het bestand word hij decrypted in een temp map neergezet dus niet in place. nu wil ik een controle inbouwen die elke minuut de decrypted bestanden weer encrypted wegzet omdat daar data in gewijzigd kan worden en dan de decrypted bestanden verwijderd.

Er werken meer mensen met deze applicatie dus vandaar de controle.

[Verwijderd]

Kappie schreef op donderdag 17 augustus 2006 @ 17:20:
weet niet de precieze functies/codes maar je zou kunnen proberen het bestand exclusief te openen. lukt dat niet dan heeft of de gebruiker daar geen rechten toe of het is al geopend (in gebruik).

Dan is dit ook geen slechte oplossing, als je toch het bestand wilt versleutelen.

[barfieldmv]

Van google:

I had noticed that Windows Explorer will let you make a copy of a locked file. Often enough, I actually copied files (mostly log files of programs running in production) so I could view them in my own log viewer. Well, I just wrote a new version that will do this automatically. If I can't open a file read-only yet it exists, I make a temp copy and then open that copy. FileInfo.CopyTo() works well for me in that scheme.

Van mezelf:

Do een try catch statement om alles te verwijderen.
Bij alles dat mislukt start een filewatcher om te kijken wanneer het bestand vrij kom of gebruik een (redelijk lange/afhankelijk van performace zo'n incrementele) timeout.

[Gerco]

Verwijderd schreef op donderdag 17 augustus 2006 @ 17:49:
Er werken meer mensen met deze applicatie dus vandaar de controle.

Ik ruik een concurrency probleem...

Is het niet beter om een file format plugin/macro voor Office te schrijven die de encrypted files on-the-fly kan decrypten en weer encrypten bij het saven? Of misschien nog beter, EFS gebruiken?

[pjvandesande]

whoami schreef op donderdag 17 augustus 2006 @ 17:32:
[...]

Mja, ik denk ook dat er geen andere oplossing is, alhoewel dit eigenlijk behoorlijk ranzig is vind ik. (En traag)

Traag? Is dat zo? Heb je het ooit getest?

Het gooien van Exceptions wordt snel als traag gemarkeerd, maar de praktijk wijst anders uit.

[whoami]

In .NET 2.0 is het gooien van exceptions al heel wat sneller. Echter, je moet eens een exceptie gooien in .NET 1.1. Het throwen van exceptions in .NET is duur, dat is een feit, en dat zie je vooral bij het throwen van de eerste exceptie. Een 2de keer een exceptie gooien gaat al wat sneller.
(Kijk maar eens je framework design guidelines boek erop na. )
In Delphi 5 bv is dat al weer heel iets anders, daar is het veel sneller.

Verder is het ook niet aangeraden om je program flow dmv exceptions te bepalen, daar zijn ze niet voor gemaakt. Echter, in dit specifieke geval zie ik ook niet direct een andere oplossing.
Je hebt hier geen 'test' methods voor deze situatie...

Zie ook hier

[pjvandesande]

Je moet je application flow niet bepalen met exceptions, maar ik heb even twee simpelen tests in elkaar gedraaid om te kijken wat de kosten nou zijn van een Exception.

Voor de nieuwsgierige onder ons: Exceptions, wat kost het?

whoami schreef op vrijdag 18 augustus 2006 @ 12:00:
In .NET 2.0 is het gooien van exceptions al heel wat sneller.

Bij mij liepen de tests onder 1.1 sneller dan onder 2.0.

[ Voor 69% gewijzigd door pjvandesande op 19-08-2006 21:10 ]