Création d'un disque virtuel

LB · 02/03/2018, 11h23

Bonjour,

(cb6)

Existe-t-il un moyen de créer un disque virtuel sans recourir à une application extérieure ?

Merci pour vos retours.

**bacelar** · 02/03/2018, 12h16

Qu'entends-tu par "disque virtuel" ?

LB · 02/03/2018, 14h57

Bonjour Bacelar,

merci de t'intéresser à mon problème.

Il s'agit de créer un disque, comme on peut le faire via la Gestion de l'ordinateur/Gestion des disques/Créer un disque dur virtuel.

Le but étant d'y copier des fichiers qui seront systématiquement détruits à la fermeture du PC.

**bacelar** · 02/03/2018, 18h39

J'ai du mal à voir le rapport entre

Il s'agit de créer un disque, comme on peut le faire via la Gestion de l'ordinateur/Gestion des disques/Créer un disque dur virtuel.

et

Le but étant d'y copier des fichiers qui seront systématiquement détruits à la fermeture du PC.

Le premier, c'est de faire un dialogue avec le Kernel pour qu'il fasse son travail de création d'un Disk "à sa sauce".
Le second, c'est implémenter un système de sécurité, si je ne me trompe pas.

J'ai du mal à comprendre comment votre démarche s'intégrer dans des mécanismes standards de sécurité, mais bon.

Pour implémenter un "virtual disk" où vous pourrez faire tout ce que vous voulez : https://www.codeproject.com/Articles...sk-for-Windows

LB · 05/03/2018, 08h35

Ce procédé me semble bien lourd à mettre en place.
Par ailleurs, il nécessite l'installation de Windows Driver Developer Kit.
Or, j'ai précisé que je ne pouvais par recourir à des applications externes.

N'y aurait-il pas une option plus light ?

Merci.

**Bousk** · 05/03/2018, 09h16

Un disque virtuel c'est loin d'être un objet simple.
Peut-être que si tu disais vraiment ce que tu comptes faire on pourrait te dire que non un disque virtuel n'est pas la solution et t'indiquer un autre truc.
Parce que bon si c'est juste pour supprimer les fichiers à l'extinction du pc... un simple script de suppression lancé à l'extinction et au démarrage et t'as gagné.

LB · 05/03/2018, 09h38

Mon application est distribuée sur des postes utilisateurs en réseau (pas de disque C).
L'application et sa base de données sont donc logées sur l'un de ces serveurs.
Je souhaite qu'à son lancement, l'application et la base frontale soient copiées sur ce "disque virtuel" afin d'éviter un encombrement du serveur (qui est déjà lent) en raison d'un grand nombre d'utilisateurs connectés.

Peut-être me direz-vous qu'un "clone" du serveur ne résoudra en rien mon problème mais c'est la solution à laquelle j'avais pensé.

**Bousk** · 05/03/2018, 10h57

Quel est l'intérêt du serveur ? Est-ce que les utilisateurs communiquent avec sa base de données ?
Si oui tu es forcément obligé d'avoir une connexion au serveur de toute façon. SI le serveur est lent, il est temps de l'upgrade ou au moins de le clean.
Si c'est juste pour télécharger l'application, pourquoi ne s'agit-il pas d'un installer à récupérer ? Avec mise à jour de l'application au lancement.
A quoi ressemble l'application ? Pourquoi ne pas faire un client léger via un browser web ?
Pourquoi ne pas mettre toutes les données en RAM ?

LB · 05/03/2018, 11h45

Je ne suis pas l'administrateur du système.
Oui, les utilisateurs communiquent avec la base de données frontale et la mise à jour de la dorsale se fait in fine par lots.
Je souhaite donc que les modifications apportées par les utilisateurs s'opèrent sur la frontale résidant sur un espace à part et que la dorsale sur le serveur ne soit mise à jour qu'au sortir de l'application.

Nombreuses connexions à la frontale par l'utilisateur et une seule au serveur lors de la fermeture.

**Christophe** · 05/03/2018, 13h38

Attention, si tu changes le chemin de la frontale, tu peux briser le lien entre la frontale et la dorsale.

On a trop peu d'éléments.

C'est quoi comme type de base ?

LB · 05/03/2018, 13h48

Le lien entre frontale et dorsale est renoué à chaque lancement.
Il s'agit d"une base ACCESS (je sais c'est un peu limite mais le système ne me permet pas d'utiliser plus performant).

**bacelar** · 05/03/2018, 16h53

Ce procédé me semble bien lourd à mettre en place.

Comme l'a indiqué @Bousk, un disque virtuel, c'est pas un joujou qu'on fait sur un coin de table.
Et je ne vois toujours pas l'utilité de ce machin super-complexe dans votre problématique.
Je pense que vous faites complètement fausse route avec ce "disque virtuel".

Par ailleurs, il nécessite l'installation de Windows Driver Developer Kit.
Or, j'ai précisé que je ne pouvais par recourir à des applications externes.

Vous n'avez donc absolument pas compris ce qu'est un SDK, comme de Windows DDK.
C'est un ensemble d'outils, de code, de fichier d'en-tête, de librairies, pour faire des applications, ou des drivers dans le cas du Windows DDK.
Ces des briques de bases pour votre chaine de compilation.

N'y aurait-il pas une option plus light ?

Oui, correctement analyser votre problème initial et ensuite concevoir une architecture pour la solution qui ne ressemble pas à une usine à gaz.

Mon application est distribuée sur des postes utilisateurs en réseau (pas de disque C).

C'est à dire ?
Des Network computer, donc sans même un "vrai" disque dur ???

L'application et sa base de données sont donc logées sur l'un de ces serveurs.

C'est donc une vieille architecture Client/Server pas super "scalable" ???

Je souhaite qu'à son lancement, l'application et la base frontale soient copiées sur ce "disque virtuel" afin d'éviter un encombrement du serveur (qui est déjà lent) en raison d'un grand nombre d'utilisateurs connectés

Et pourquoi toute cette ribambelle de base de données à synchroniser plutôt qu'un simple client/server avec connexion par polling pour avoir une meilleur "scalabilité" ?

Peut-être me direz-vous qu'un "clone" du serveur ne résoudra en rien mon problème mais c'est la solution à laquelle j'avais pensé.

A moi de ne rien comprendre à votre problème initial, oui, je pense que cela ne résoudra rien à votre problème mais ajouterait un énorme niveau de complexité et une chute du niveau d'utilisabilité de votre application.

La "solution" que vous proposez ressemble, dans votre discours, à une approche base centrale/base déportée sauf que ce n'est absolument comme cela que s'implémente.
Il faut passer par de l'outillage spécifique à ce type de solution.

Il existe bien des solutions plus légères que ce type d'approche, à réserver à des cas particuliers, comme des connexions réseaux non-permanentes.

Je ne suis pas l'administrateur du système.

Et ?
La solution que vous devrez choisir devra de toute façon avoir l'aval de vos administrateurs système/réseaux/sécurité.

Oui, les utilisateurs communiquent avec la base de données frontale et la mise à jour de la dorsale se fait in fine par lots.
Je souhaite donc que les modifications apportées par les utilisateurs s'opèrent sur la frontale résidant sur un espace à part et que la dorsale sur le serveur ne soit mise à jour qu'au sortir de l'application.

C'est un mode d'utilisation extrêmement dégradé, est-ce déjà le cas actuellement ou est-ce un effet de votre "solution" ?
Quitte à avoir déjà ce type de workflow asynchrone, autant passer par des outils dédiés plus fiables comme les files de messages MSMQ, ou autres.

Nombreuses connexions à la frontale par l'utilisateur et une seule au serveur lors de la fermeture.

C'est quoi cette architecture de shadocks ???
Normalement, il n'y a qu'une connexion entre le serveur frontal et l'utilisateur tout au long d'une interaction client/serveur.
S'il y a plusieurs connections transitoires entre l'utilisateur et le serveur, il n'y aurait pas de problème de monté en charge et donc le problème n'aurait pas lieu d'être.

EDIT :

Il s'agit d"une base ACCESS (je sais c'est un peu limite mais le système ne me permet pas d'utiliser plus performant).

Bon, bin, la solution est évidente, on dégage ACCESS !!!