[Base de donnée] Liens physiques, langage C

Version imprimable

04/07/2006, 17h03
Ricks

[Base de donnée] Liens physiques, langage C

Bonjour à tous.

J'aimerais pouvoir créer des liens physiques sur fichiers mais je ne sais absolument pas s'il existe une commande en C pour cela.
J'ai besoin que mon programme soit portable Windows,Unix/Linux.
Alors si on ne peut le faire en C, j'aimerais savoir la commande pour Windows car je ne connais que celle d'Unix (ln <fichier existant> <nouveau>). Je testerais alors au préalable le système d'exploitation avant d'utiliser la commande system, mais ce serait bien dommage qu'on ne puisse pas faire ça avec une commande en C :cry:

Merci ;)
04/07/2006, 17h20
PRomu@ld

Citation:

j'aimerais savoir la commande pour Windows car je ne connais que celle d'Unix

A ma connaissance, il n'y a pas de lien sous windows comme sous UNIX.

De plus comme il s'agit de notion de programmation système, le langage C n'est qu'un support, il n'y a pas de fonctions propre au langage qui puisse faire ce que tu veux.

Sinon si tu veux éviter la commande system, tu as symlink définie dans unistd.h, mais ça reste une fonction dispo sur les systèmes UNIX uniquement
04/07/2006, 17h30
Ricks

Citation:

A ma connaissance, il n'y a pas de lien sous windows comme sous UNIX.

C'est bien ce que je craignais : sous Windows je ne connais que l'utilisation des liens symboliques mais pas de liens physiques comme sous UNIX.

Citation:

De plus comme il s'agit de notion de programmation système, le langage C n'est qu'un support, il n'y a pas de fonctions propre au langage qui puisse faire ce que tu veux.

J'espérais qu'il existe une fonction du même type que mkdir() que j'ai été surpris (je l'avoue ;)) de voir fonctionner en C.

Et merci bien pour ta dernière info, je vais tester la chose.
04/07/2006, 17h35
PRomu@ld

mkdir est une fonction POSIX, ça n'est pas une fonction du langage C.
05/07/2006, 10h16
Ricks

Ah d'accord. Donc c'est une fonction portable.

J'aurais du donc demander au début de mon post :
Existe-t-il une fonction POSIX qui permette de créer des liens physiques ?

Je suppose que c'est non mais je vais attendre, on ne sait jamais ;)

Merci pour ces explications
05/07/2006, 10h52
Ricks

Plus d'explications sur mon projet :

Le programme que je souhaiterais créer permettrait d'utiliser (ajout, suppression, liste, copie,...) une base de données regroupant différentes IP (intellectual property), chacune ayant plusieurs versions. A chaque nouvelle version d'un IP, il faudrait faire des liens sur les fichiers existants et copier les nouveaux fichiers. Les liens permettraient un gain de place considérable. Il est nécessaire d'utiliser des liens physiques et non pas symbolique car on doit pouvoir supprimer certains fichiers si on le souhaite ultérieurement.

Voilà, c'est le dernier rempart à la portabilité de mon programme.
Peut-être verrez-vous un autre moyen de gagner de la place qui m'aurait échappé.

Merci d'avance
05/07/2006, 12h08
Ricks
Je crois avoir trouvé.
Merci pour tes réponses, cela m'a permis de faire une meilleure recherche avec google et j'ai trouvé ce site :
http://www2.lifl.fr/~marquet/cnl/pds/fs.pdf

Page 38 : Créer un lien physique
Code:

1 2 #include <unistd.h> int link(const char *old, const char *new);
symlink que tu m'avais dit est l'équivalent pour les liens symboliques et, d'après ce site, ces 2 fonctions seraient des fonctions POSIX (titre p24) et ne marcheraient donc pas uniquement sur UNIX.

Je vais tester cela.
Encore merci !
05/07/2006, 12h38
PRomu@ld

Citation:

symlink que tu m'avais dit est l'équivalent pour les liens symboliques et, d'après ce site, ces 2 fonctions seraient des fonctions POSIX (titre p24) et ne marcheraient donc pas uniquement sur UNIX.

Ces fonctions sont intimement liées au SGF, par conséquent, j'ai des doutes sur la portabilité.

Citation:

Le programme que je souhaiterais créer permettrait d'utiliser (ajout, suppression, liste, copie,...) une base de données regroupant différentes IP (intellectual property), chacune ayant plusieurs versions. A chaque nouvelle version d'un IP, il faudrait faire des liens sur les fichiers existants et copier les nouveaux fichiers. Les liens permettraient un gain de place considérable. Il est nécessaire d'utiliser des liens physiques et non pas symbolique car on doit pouvoir supprimer certains fichiers si on le souhaite ultérieurement.

Pourquoi n'utilises-tu pas des pointeurs pour faire le lien avec les fichiers existants ? (en gros tu fait abstraction du système et tu ne passes que par les fonctionnalités du langage)
05/07/2006, 16h24
Ricks

En effet, link et symlink ne sont pas portables. Le créateur de ce site devait travailler sur UNIX et n'a donc pas vu que ces fonctions n'étaient pas POSIX. Faux espoir !!!!! :(

Sinon, pour ce qui est des pointeurs, je ne te suis pas du tout. Comment reproduire une telle arborescence avec des pointeurs ? Et comment enregistrer ces pointeurs ? Dans un fichier texte ?
05/07/2006, 16h32
PRomu@ld

Citation:

Sinon, pour ce qui est des pointeurs, je ne te suis pas du tout. Comment reproduire une telle arborescence avec des pointeurs ? Et comment enregistrer ces pointeurs ? Dans un fichier texte ?

En fait, j'ai lu un poil trop vite ... Ce que tu peux faire, c'est stoquer dans un fichier, l'arborescence pour atteindre le fichier de donnée. Ca fait une sorte de pointeur (au lieu de stoquer l'adresse d'une variable mémoire, tu stoques l'adresse, dans le format du système de fichier, des fichiers que tu veux accèder)
05/07/2006, 16h51
Ricks

Citation:

Ce que tu peux faire, c'est stoquer dans un fichier, l'arborescence pour atteindre le fichier de donnée. Ca fait une sorte de pointeur (au lieu de stoquer l'adresse d'une variable mémoire, tu stoques l'adresse, dans le format du système de fichier, des fichiers que tu veux accèder)

Aie aie aie... J'y avais pensé au début mais j'avais abandonné l'idée car c'est assez monstrueux vu la taille que va avoir l'arborescence. :?
Je pense que je vais devoir abandonner la portabilité et me cantonner à Linux/UNIX avec la fonction link(new,old). L'utilisation de la base aurait été de toute façon faible pour Windows mais je m'étais lancé un défis pour la portabilité... j'ai perdu :(

Encore merci de m'avoir orienté vers la fonction link !
05/07/2006, 16h55
PRomu@ld

Citation:

Aie aie aie... J'y avais pensé au début mais j'avais abandonné l'idée car c'est assez monstrueux vu la taille que va avoir l'arborescence.

Je vois pas le problème, tes fichiers de données seront significativement plus gros que les fichiers d'adresse (sinon la recopie des données est plus efficace). Tu n'as qu'à stoquer le chemin.
05/07/2006, 16h57
KiLVaiDeN

Question : depuis quand "POSIX" est équivalent à "Compatible Windows" ?

Désolé mais je crois que c'est une utopie ;)
05/07/2006, 17h20
Ricks

Citation:

Je vois pas le problème, tes fichiers de données seront significativement plus gros que les fichiers d'adresse (sinon la recopie des données est plus efficace). Tu n'as qu'à stoquer le chemin.

Je disais monstrueux non pas pour l'espace sur le disque mais pour le code que je vais devoir ajouter dans chacun des programmes (ajout,suppr,list,copy). :lol: Car ce n'est jamais fichier par fichier mais plutôt des groupes de fichiers ou plus souvent des groupes de répertoires contenant des groupes de fichiers.

Mais je vais peut être me motiver et essayer !

Citation:

Question : depuis quand "POSIX" est équivalent à "Compatible Windows" ?

J'y ai cru en lisant ceci : http://fr.wikipedia.org/wiki/IEEE_1003

et plus précisément ceci :

Citation:

Bien qu'il soit principalement implémenté sur des systèmes de type UNIX, le standard POSIX peut être utilisé par n'importe quel autre système d'exploitation. Par exemple, Microsoft Windows NT est conforme à POSIX.1, ce qui est suffisant pour des programmes POSIX relativement simples.

Mais je ne dois pas bien comprendre, je ne m'y connais pas du tout en OS.
05/07/2006, 17h29
PRomu@ld

Citation:

Je disais monstrueux non pas pour l'espace sur le disque mais pour le code que je vais devoir ajouter dans chacun des programmes (ajout,suppr,list,copy).

Avec un bon module (en fait pas si énorme que ça) ça devrait le faire et pour tes appels, ça sera moins long que lynk/symlink( car tu fais les vérifications dans ton module )

Citation:

Mais je ne dois pas bien comprendre, je ne m'y connais pas du tout en OS.

Wikipedia indiquait le support POSIX.1 (il y a plusieurs POSIX en fait ...) link et symlink ne sont pas POSIX.1 donc pas pour Windows.

Si tu veux plus d'info sur POSIX la page anglaise de wikipedia est à mon sens meilleure :

http://en.wikipedia.org/wiki/POSIX
05/07/2006, 17h40
Ricks

Citation:

Wikipedia indiquait le support POSIX.1 (il y a plusieurs POSIX en fait ...) link et symlink ne sont pas POSIX.1 donc pas pour Windows.

Ah d'accord merci ;)

J'ai réfléchi à cette méthode, et ce n'est pas si simple qu'on pourrait le penser à première vue. Par exemple, si je supprime une version, les liens dans le fichier texte de la version suivante ne fonctionneront plus. Il faudrait les remettre à jour à chaque delete. Et ces liens peuvent être relié à n'importe quelle version précédente. Il faudrait alors à chaque suppression vérifier si dans les fichiers textes de toutes les versions suivantes, il n'y a pas un lien relié à ce qu'on va delete. Alors il faudrait le modifier et faire un nouveau lien sur le même fichier sur une des versions antérieures (elle ne contiendrait pas toutes le fichier vu qu'elles peuvent avoir elle même des liens). Un gros bordel quoi :lol:

Si on n'utilise pas des liens physiques, on se retrouve avec ta méthode qui serait plutôt un équivalent des liens symboliques et c'est carrément plus dur à gérer :mouarf:
L'avantage des liens physiques est que si l'on souhaite supprimer le fichier alors qu'il y a d'autres liens physiques qui le relie, le fichier ne sera pas détruit mais seulement le lien. Alors qu'avec un lien symbolique, si on supprime, ça va le détruire et tous les liens seront morts :(

Tant pis, ça devient beaucoup trop compliqué pour peu d'usage (Windows), donc je reste sous Linux/UNIX.

Encore merci pour les différentes explications !
05/07/2006, 17h46
PRomu@ld

Citation:

L'avantage des liens physiques est que si l'on souhaite supprimer le fichier alors qu'il y a d'autres liens physiques qui le relie, le fichier ne sera pas détruit mais seulement le lien. Alors qu'avec un lien symbolique, si on supprime, ça va le détruire et tous les liens seront morts

Tu peux utiliser une technique que l'on utilise quelque fois en POO : le compteur de référence. Tu stoques le nombre de liens qui sont fait vers ton fichier de donnée. (c'est exactement ce qui se passe dans les SGF , avec différentes tables qui maintiennent tout ça en place).

Si tu veux supprimer ton fichier, tu regardes le compteur et s'il est 0, alors tu peux supprimer, s'il est plus grand alors tu supprimes uniquement ton lien.
07/07/2006, 11h50
Ricks

Il y a un problème quand on veut supprimer le répertoire contenant le fichier original. On verra avec ta méthode qu'il y a des liens qui pointent dessus mais on souhaite quand même le supprimer. Il faudrait alors le déplacer dans la version suivante à la place du lien symbolique qui lui était destiné, ensuite il faudrait faire pointer tous les autres liens symboliques sur ce nouveau fichier (vu que ça ne se fera pas automatiquement avec la copie et qu'il faudra modifier, pour tous, les chemins qui les liaient au fichier original afin qu'ils pointent sur la nouvelle copie), et seulement après, on pourrait supprimer le fichier original. J'essaierais peut être par la suite cette méthode mais, là, je n'ai pas le temps de faire quelque chose d'aussi complexe. Je vais devoir utiliser les liens physiques et donc me restreindre à Linux/UNIX pour l'instant.

Merci pour tes réponses, j'ai pu ainsi apprendre pas mal de choses, en particulier sur le fonctionnement des OS ;)