Problème de partage de fichier...

"Ignace"

Bonjour à tous.

J'ai réalisé un petit automate d'envoi de mail dans le cadre d'un gros
projet (envoi des phases importantes -pannes, fin de processus- à
l'administrateur).

Interface multiple (par java, VBA, batch, scripts, .NET)

Principe :
Un fichier formaté "maison" (destinataire, sujet, corps) -pas XML, texte
simple- est déposé dans un répertoire guetté par mon application.
Celle ci se "réveille" lit le(s) fichier(s), l'analyse et le traite puis
l'archive dans un répertoire dédié.

Or j'ai parfois des problèmes d'accès du genre (en substance : de mémoire)
"Exception : le fichier .... est utilisé par une autre application".

Alors que la seule application est 'la mienne'.
Cet utilitaire est écrit en C#, impossible de localiser quelle est
l'application polluante.
En insistant beaucoup (try/catch "insistant"), le fichier finit par être
digéré, parfois après plusieurs secondes.

J'ai utilisé un espion de fichier (FileMon) : j'ai un problème de partage
lors de l'ouverture. Pas moyen de savoir par "qui" est locké le fichier.

PS : j'ai essayé de désactiver l'antivirus : même problème.

Des pistes ?

Bonjour,

En .NET les fichiers sont fermés quand l'objet fichier est détruit. Le
Close() ne fonctionne pas tojours (dépend de la classe)
Le mieux est de faire
using (System.IO.FileStream fs = new System.IO.FileStream(fileName, ...))
{
// accèder au fichier
}
// Ici tu es certain que le fichier est fermé car l'objet est explicitement
détruit.

Sinon c'est le garbage collector qui fermera ton fichier et tu ne sais pas
quand il agit, d'où tes quelques secondes d'indisponibilités.

Rémi

--
Rémi THOMAS
MVP Visual C++ .NET
http://www.pixel-technology.com/rthomas

"Remi THOMAS" <remi@xtware.com> a écrit dans le message de news:
43ecab21$0$27934$626a54ce@news.free.fr...

"Ignace"

Bonjour à tous.

J'ai réalisé un petit automate d'envoi de mail dans le cadre d'un gros
projet (envoi des phases importantes -pannes, fin de processus- à
l'administrateur).

Interface multiple (par java, VBA, batch, scripts, .NET)

Principe :
Un fichier formaté "maison" (destinataire, sujet, corps) -pas XML, texte
simple- est déposé dans un répertoire guetté par mon application.
Celle ci se "réveille" lit le(s) fichier(s), l'analyse et le traite puis
l'archive dans un répertoire dédié.

Or j'ai parfois des problèmes d'accès du genre (en substance : de
mémoire)
"Exception : le fichier .... est utilisé par une autre application".

Alors que la seule application est 'la mienne'.
Cet utilitaire est écrit en C#, impossible de localiser quelle est
l'application polluante.
En insistant beaucoup (try/catch "insistant"), le fichier finit par être
digéré, parfois après plusieurs secondes.

J'ai utilisé un espion de fichier (FileMon) : j'ai un problème de partage
lors de l'ouverture. Pas moyen de savoir par "qui" est locké le fichier.

PS : j'ai essayé de désactiver l'antivirus : même problème.

Des pistes ?

Bonjour,

En .NET les fichiers sont fermés quand l'objet fichier est détruit. Le
Close() ne fonctionne pas tojours (dépend de la classe)
Le mieux est de faire
using (System.IO.FileStream fs = new System.IO.FileStream(fileName, ...))
{
// accèder au fichier
}
// Ici tu es certain que le fichier est fermé car l'objet est
explicitement détruit.

Sinon c'est le garbage collector qui fermera ton fichier et tu ne sais pas
quand il agit, d'où tes quelques secondes d'indisponibilités.

Rémi

--
Rémi THOMAS
MVP Visual C++ .NET
http://www.pixel-technology.com/rthomas

Merci pour l'info je vais essayer...
lundi.

Ca marche parfaitement sur mon PC perso (XP familial)
La panne est, en apparence, uniquement sur 200x serveur.

(Je fais bien un close() sur un TextStreamReader :
"vieillard" du C++, je ne fais pas trop confiance au ramasse-miettes)

--
Ignace

"Remi THOMAS" <remi@xtware.com> écrivait
news:43ecab21$0$27934$626a54ce@news.free.fr:

Sinon c'est le garbage collector qui fermera ton fichier et tu ne sais
pas quand il agit, d'où tes quelques secondes d'indisponibilités.

D'où l'imbécilité d'implementer un GC dans un langage orienté objet. C'est
le gros reproche que je fais a Java et je ne comprends pas pourquoi MS a
copié cette "fonctionnalité" dans leur clone du langage de chez Sun.

Bonjour,

D'où l'imbécilité d'implementer un GC dans un langage orienté objet.
C'est le gros reproche que je fais a Java et je ne comprends pas
pourquoi MS a copié cette "fonctionnalité" dans leur clone du langage
de chez Sun.

Gasp!

Si on considère l'économie en lignes de code et le nombre de bugs et de
fuites mémoire qu'un GC va éviter, je n'utiliserai pas le mot
"imbécilité". Le GC de .Net est un outil sophisitiqué et peu intrusif.
Le fait que les objets ne soient pas détruits de manière déterministe
est un inconvénient que l'on peut gérer facilement avec l'interface
IDisposable. En tous cas, cet inconvénient ne me ferait pas renoncer aux
bénéfices d'un GC bien implémenté, ce qui est le cas dans .Net.

Par ailleurs, petite mise au point: .Net n'est pas un "clone" du langage
Java car ce n'est pas un langage mais une technologie multilangage.
C'est d'ailleurs un de ses nombreux avantages sur Java. Par contre, on
peut dire que J# est un clone du langage Java. De plus, le GC n'est pas
lié à un langage mais contrôlé par le CLR, ce qui est très différent.

--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr

> Par ailleurs, petite mise au point: .Net n'est pas un "clone" du
langage Java car ce n'est pas un langage mais une technologie
multilangage.

Tu peux certes l'attaquer par divers langages, mais c'est strictement le
même principe. C'est pas un clone, c'est du plagiat :-).

--
Arnold McDonald (AMcD)

http://arnold.mcdonald.free.fr/

"Patrick Philippot" <patrick.philippot@mainsoft.xx.fr> écrivait news:dssbnd
$301q$1@biggoron.nerim.net:

Gasp!

Si on considère l'économie en lignes de code et le nombre de bugs et de
fuites mémoire qu'un GC va éviter, je n'utiliserai pas le mot
"imbécilité".

Le GC serait surtout utile dans un langage non objet (un des pricipal
problème du C est qu'il faut être très rigoureux pour éviter les fuites
mémoires). En C++ c'est beaucoup plus facile d'éviter ces fuites avec un
minimum de discipline (les new dans le contructeur, les delete necessaires
dans le destructeur).

Le GC de .Net est un outil sophisitiqué et peu intrusif.
Le fait que les objets ne soient pas détruits de manière déterministe
est un inconvénient que l'on peut gérer facilement avec l'interface
IDisposable.

Si on doit, à chaque fois que l'on utilise un objet utilisant une ressource
système (fichier, BD, ...) faire une manip spécifique pour éviter le cas du
début de fil (sans compter les eventuels dead-lock possibles) on revient
aux inconvenients d'un language non-objet où la libération des ressources
doit se faire explicitement et non pas implicitement (comme dans le C++
avec les destructeurs).

T'emploie le bon mot : deterministe. Windows a deja du mal a avoir un
comportement deterministe, pas la peine de rajouter des elements permettant
à Murphy de foutre son grain de sable.

En tous cas, cet inconvénient ne me ferait pas renoncer aux
bénéfices d'un GC bien implémenté, ce qui est le cas dans .Net.

Si il était bien implementé le GC aurait detecté que le fichier ouvert par
Ignace était utilisé par une classe en instance de suppression dans le GC,
et aurait supprimé cette classe afin de permettre la réouverture du
fichier.

Par ailleurs, petite mise au point: .Net n'est pas un "clone" du langage
Java car ce n'est pas un langage mais une technologie multilangage.
C'est d'ailleurs un de ses nombreux avantages sur Java.

Je n'y vois pas un forcemnent un avantage.

Par contre, on

peut dire que J# est un clone du langage Java. De plus, le GC n'est pas
lié à un langage mais contrôlé par le CLR, ce qui est très différent.

Je n'ai pas parlé de langage en paticulier dans le message précédent, mais
du bouzin .Net/CLR.

Arnold McDonald (AMcD) wrote:

Tu peux certes l'attaquer par divers langages, mais c'est strictement
le même principe. C'est pas un clone, c'est du plagiat :-).

Pas d'accord :-) . D'un point de vue architecture il y a des différences
fondamentales qui expliquent d'ailleurs les différences de performances.
Java est basé sur l'idée d'une Machine Virtuelle qui interprète des byte
codes. Si quelqu'un a vu la moindre notion de machine virtuelle en .Net
qu'il me fasse signe rapidement.

En .Net pas de byte codes mais un langage assembleur portable et
lisible, le MSIL. Autre différence de taille.

Y a-t-il une notion d'Application Domain en Java?

--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr

Patrick Philippot wrote:

Pas d'accord :-).

C'est ton droit.

D'un point de vue architecture il y a des
différences fondamentales qui expliquent d'ailleurs les différences
de performances.

Je ne dis pas le contraire. Je dis juste que VM Java ou .Net, c'est kif-kif
conceptuellement.

Si quelqu'un a vu la moindre notion de
machine virtuelle en .Net qu'il me fasse signe rapidement.

C'est facile. Cela commence ici :

http://msdn.microsoft.com/netframework/ecma/

Tu peux y lire, dans
http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-335.pdf,
le concept de virtual execution system, le VES. P. 77, tu y lis :

"The Virtual Execution System (VES) provides an environment for executing
managed code. It provides direct support for a set of built-in data types,
defines a hypothetical machine with an associated machine model and state, a
set of control flow constructs, and an exception handling model. To a large
extent, the purpose of the VES is to provide the support required to execute
the CIL instruction set."

Tu trouves un beau pdf (à peu près le même) ici, dans "CLI Partition I -
Concepts and Architecture" de :

http://download.microsoft.com/download/f/9/a/f9a26c29-1640-4f85-8d07-98c3c0683396/partition_i_architecture.zip

En .Net pas de byte codes mais un langage assembleur portable et
lisible, le MSIL. Autre différence de taille.

Aucune différence, c'est le même concept. Ici :

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconMicrosoftIntermediateLanguageMSIL.asp

je lis :

"When compiling to managed code, the compiler translates your source code
into Microsoft intermediate language (MSIL), which is a CPU-independent set
of instructions that can be efficiently converted to native code. MSIL
includes instructions for loading, storing, initializing, and calling
methods on objects, as well as instructions for arithmetic and logical
operations, control flow, direct memory access, exception handling, and
other operations. Before code can be run, MSIL must be converted to
CPU-specific code, usually by a just-in-time (JIT) compiler. Because the
common language runtime supplies one or more JIT compilers for each computer
architecture it supports, the same set of MSIL can be JIT-compiled and run
on any supported architecture."

Ha bon, c'est pas le même concept que les byte code ? Dites, z'êtes pas en
forme en 2006 messieurs les MVPs...

--
Arnold McDonald (AMcD) - Help #22 /2006

http://arnold.mcdonald.free.fr/

"Patrick Philippot" écrivit

Arnold McDonald (AMcD) wrote:

Tu peux certes l'attaquer par divers langages, mais c'est strictement
le même principe. C'est pas un clone, c'est du plagiat :-).

Pas d'accord :-) . D'un point de vue architecture il y a des différences
fondamentales qui expliquent d'ailleurs les différences de performances.
Java est basé sur l'idée d'une Machine Virtuelle qui interprète des byte
codes. Si quelqu'un a vu la moindre notion de machine virtuelle en .Net
qu'il me fasse signe rapidement.

En .Net pas de byte codes mais un langage assembleur portable et lisible,
le MSIL. Autre différence de taille.

Patrick,
Cela reste quand même dans la même philosophie.
Le but final est de "Jiter" le code, c'est à dire d'avoir du code
assembleur:
- c'est le plus rapide
- tu ne l'interpretes qu'une fois

puis l'execution est managé, cad toute opération incorrecte est impossible
(écrasement de pile, débordements...)

Pour la petite histoire, .NET à commencé chez MS Research vers 1996.
A l'époque la meilleur marchine virtuelle Java sur plate forme Windows était
celle de Microsoft.
.NET devait tourner sur cette machine virtuelle.

Les modifications que Microsoft à fait (interop COM par exemple) n'a pas plu
à Sun, d'ou le célébre procés.
Le projet .NET à donc changé de stratégie en dévelopant son propre
environnement d'execution.

Rémi

"Patrick Philippot" <patrick.philippot@mainsoft.xx.fr> écrivait news:dssksk
$1u6$1@biggoron.nerim.net:

En .Net pas de byte codes mais un langage assembleur portable et
lisible, le MSIL. Autre différence de taille.

Je vois pas trop la différence. Dans un cas t'as un byte code a interpréter
et dans l'autre un pseudo-asm a compiler.

La seule différence est que, si je me rappelle bien, .Net mets en cache les
assembly resultant des pseudo compilation et ne le fait donc qu'une seule
fois. Java pourrait (devrait ?) faire la même chose : plutôt qu'une JVM,
compiler le byte code pour generer un exe compatible avec la platforme.