Refaire la commande cp avec des appels système

Version imprimable

23/09/2015, 01h29
TuxThePenguin

Refaire la commande cp avec des appels système
Bonsoir,

Je dois réaliser un programme en C qui reprend dans les grandes lignes la commande cp du terminal (sans ses options, juste la commande de base) en utilisant les appels système. Donc les fonction telles que open, write, read, fstat...

Dans les faits, lire un fichier avec read et écrire dans un autre avec write en y allant caractère par caractère pour effectuer le copier-coller, je sais le faire. Mon problème se pose sur la création du nouveau fichier. L'exécution doit avoir "la même forme" que cp donc comme suit:
```
./cp  /.../fichierSource  /.../repertoireDest/ 
```
Sauf que voilà, je n'arrive pas à créer mon fichier dans le répertoire de destination. Si il n'y avait pas de répertoire spécifique pour la destination ça aurait été simple, je serais passé par open avec les modes correspondants (O_CREAT et O_WRONLY) ou par creat. Comment je dois m'y prendre pour faire ceci sachant que la concaténation de mon argv[2] et argv[1] n'est pas possible car argv[1] peut ne pas avoir seulement le nom du fichier à copier mais également son chemin d'accès (absolu ou relatif) ? Et d'ailleurs, je ne suis pas sûr que j'ai le droit d'utiliser la bibliothèque string.h dans mon programme pour faire une concaténation.

Auriez-vous une solution à cela ? Comment créer le fichier dont le nom sera identique au fichier source (selon la condition que l'on se trouve dans un répertoire autre) mais à un emplacement bien spécifique ?

Merci de votre aide.
23/09/2015, 09h20
ternel

Tu lis le chemin du fichier source pour extraire le nom du fichier (équivalent de la commande basename): le fichier commence après le dernier séparateur de chemin ('/' ou un des champs de locale?).

Il te faudra aussi détecter si le chemin cible désigne un dossier existant ou un futur fichier.
24/09/2015, 00h28
TuxThePenguin

Merci pour la réponse. J'ai vu qu'il y avait la fonction basename dans libgen.h mais aussi dirname pour isoler le chemin d'accès. Je vais reprendre l'élaboration du code et je reviendrais vers vous en cas de besoins.
24/09/2015, 21h23
TuxThePenguin

C'est bon j'ai pu réaliser ma fonction cp basique, basename et dirname m'ont aidé a écrire le le chemin associer au nom du fichier en fonction de condition comme la copie dans le même dossier.
26/09/2015, 07h20
Sve@r
Citation:

Envoyé par TuxThePenguin

Auriez-vous une solution à cela ? Comment créer le fichier dont le nom sera identique au fichier source (selon la condition que l'on se trouve dans un répertoire autre) mais à un emplacement bien spécifique ?

Bonjour

En fait, la règle de gestion de la commande cp ne se base pas sur notre position (répertoire autre) mais sur la façon dont on l'invoque
- soit il y a toute une liste de noms (exemple cp xxx yyy zzz aaa bbb ccc) et dans ce cas, le dernier nom de la liste doit impérativement être un nom de dossier et ainsi tous les autres fichiers qui précèdent y sont copiés en gardant leur nom d'origine (donc ici ce sera ccc/xxx, ccc/yyy, ccc/zzz, ccc/aaa, ccc/bbb).
- soit il n'y a que deux noms (exemple cp xxx yyy) et dans ce cas, soit le second nom est juste un nom de fichier et la commande recopie le premier dans le second, soit c'est un nom de dossier et dans ce cas elle se comporte comme dans le premier cas
Bien entendu, cela n'empêche pas les problèmes. Notemment si plusieurs fichiers ont le même "nom de base" car seul ce dernier est pris en compte quand elle copie dans un dossier (exemple cp d1/xxx d2/xxx d3/xxx dossier_dest) => le permier "d1/xxx" sera copié et chacun des autres "xxx" fera l'objet d'une question pour savoir s'il doit l'écraser (sauf si on a rajouté l'option "-f" (force) à la commande).
26/09/2015, 09h38
Bktero

Merci de cliquer sur le bouton :resolu: en bas de page si le problème est effectivement résolu :)
29/09/2015, 21h09
TuxThePenguin

Merci de ta réponse Sve@r.

Je n'avais pas pensé à ces conditions-là. J'ai donc réadapté mon code pour faire de la copie de multiple fichier dans un même répertoire.

Par contre, je me pose une question, afin de savoir si le dernier argument entré est un répertoire, j'utilise l'appel système stat et regarde ensuite ce qu'il résulte de la fonction IS_DIR sur argv[argc-1]. Cependant en reprenant ton second exemple d'exécution de cp (la copie d'un fichier sous un nouveau nom), le second argument sera un fichier inexistant jusqu'alors. Si je souhaite intégrer ceci dans mon code, je ne peut utiliser stat et ensuite IS_REG sur argv[2] afin de savoir si c'est un fichier car ce dernier n'existe pas encore.
Je cherche surement le compliqué là où il n'est pas, car si argv[2] n'est pas un répertoire, on peut se dire qu'il est forcément un fichier et faire dans e cas la copie sous un nouveau nom, mais ne pourrait-il pas être autre chose qu’un fichier nous empêchant donc cette copie sous nouveau nom?

Je voudrais également savoir, pour toutes ces commandes intégrées au système comme cp, ls, cat, mv.... Dans un langage comme le c (ou autre) puis compilé ou elles ont été réalisé autrement ? Comment ont elles été codé? Dans un langage comme le c (ou autre) puis compilé ou elles ont été réalisé autrement ?

Merci
29/09/2015, 23h04
Sve@r
Citation:

Envoyé par TuxThePenguin

Cependant en reprenant ton second exemple d'exécution de cp (la copie d'un fichier sous un nouveau nom), le second argument sera un fichier inexistant jusqu'alors. Si je souhaite intégrer ceci dans mon code, je ne peut utiliser stat et ensuite IS_REG sur argv[2] afin de savoir si c'est un fichier car ce dernier n'existe pas encore.
Je cherche surement le compliqué là où il n'est pas, car si argv[2] n'est pas un répertoire, on peut se dire qu'il est forcément un fichier et faire dans e cas la copie sous un nouveau nom, mais ne pourrait-il pas être autre chose qu’un fichier nous empêchant donc cette copie sous nouveau nom?

Dans Unix/Linux tout est fichier. Mais tout fichier n'est pas forcément équivalent l'un par rapport à l'autre.
Tu as
- le fichier classique ou ordinaire (fichier texte, document tableur, film, musique, image). C'est le fichier de base. Sa caractéristique est qu'il n'a aucune caractéristique ou structure spécifique reconnaissable par Unix ; même si sa structure est reconnaissable par un logiciel particulier (vlc, gimp, libreoffice, etc)
- le dossier (ou répertoire). C'est une entrée à 2 colonnes contenant 1) un nom de fichier et 2) un n° d'inode. Grace à ce mécanisme, le système peut retrouver quel dossier contient quel fichier et comment y accéder quand on demande à l'ouvrir
- le pipe (outil de communication bloquant entre 2 processus)
- le socket (outil de communication non bloquant entre 2 processus)
- le device (fichier dédié aux périphériques IO). Ils sont de 2 type: "b" (IO mode "block" comme le disque), et "c" (IO mode "caractère, comme l'écran). Ce ne sont pas vraiment des fichiers dans le sens conventionnel mais plutôt des points d'entrée vers l'endroit où le noyau gère ses périphériques
- le lien symbolique (les raccourcis zindow en sont une pâle copie). Il s'agit d'un fichier contenant le nom d'un autre fichier. Mais pour que le système sache que ce nom est un nom de fichier (et non un simple contenu texte), il faut que ce fichier soit typé différemment
Il existe aussi le type "lien réel" mais comme il ne s'agit que d'un autre nom relié à un même n° d'inode, et que le type d'un fichier se situe dans son inode, on peut alors l'assimiler au fichier auquel il est lié

La copie ne peut pas s'appliquer aux devices, ni aux sockets ou aux pipes. Elle pourrait s'adresser au lien symbolique mais les primitives système, quand on accède au lien symbolique, vont automatiquement s'adresser au fichier qui y est référencé donc ce type là est squeezé y compris par stat() qui ne sait pas voir les liens symboliques. Seule lstat() sait les distinguer. La copie d'un répertoire pourrait revenir à recréer un second répertoire contenant les mêmes noms de fichier que le premier ce qui serait peu utile donc dans ce cas précis, et avec une option appropriée, la commande crée un second répertoire et y copie tous les fichiers qui s'y trouvent y compris en récursif si le repertoire en contient d'autres (ceci dit, je n'ai jamais testé la copie d'un répertoire qui contiendrait des fichiers exotiques comme devices ou sockets). Mais je ne pense pas que ton prof te demande d'aller si loin.
Donc finalement avec un peu de réflexion (et d'intuition) on se rend compte que le cp ne s'appliquera qu'aux fichiers dits "classiques". Si tu veux le reproduire, il te faut donc juste tester S_ISREG et éventuellement S_ISDIR. Ou plutôt S_ISDIR sur le dernier nom et si ce n'est pas bon, alors tu dois avoir impérativement avoir 2 et seulement 2 noms et le dernier répondant au S_ISREG.
Puis chacun des autres fichiers précédents ce dernier doivent, eux, juste répondre au S_ISREG et sinon pour chaque fichier n'y répondant pas, tu le squeeze.

Citation:

Envoyé par TuxThePenguin

Je voudrais également savoir, pour toutes ces commandes intégrées au système comme cp, ls, cat, mv.... Dans un langage comme le c (ou autre) puis compilé ou elles ont été réalisé autrement ? Comment ont elles été codé? Dans un langage comme le c (ou autre) puis compilé ou elles ont été réalisé autrement ?

Unix/Linux ont été écrits en C. C'est pour ça que le C est si plébiscité dans le monde Unix/Linux => tu peux à loisir taper dans le système avec ton propre code en utilisant les primitives système (primitives utilisées aussi par les commandes classiques).
29/09/2015, 23h46
TuxThePenguin

Merci pour tous ces renseignements qui m'auront été bien utiles. Je viens de commencer mes cours de système d'exploitation et ceci a pu éclaircir certains points.

J'avais déjà vu la partie sur les liens symbolique et les liens physique. Saurais-tu pourquoi cette notion de lien physique n'a pas été implémenter sous les systèmes Windows contrairement au liens symboliques faisant référence aux raccourcis sous Windows ?

Et par curiosité si ce n'est pas indiscret, depuis quand t'intéresses-tu à l'univers unix/linux et parcours donc ce système d'exploitation ? Car tu as l'air d'avoir pas mal de connaissance sur ce domaine au niveau du fonctionnement du système d'exploitation et e sont architecture.

Je passe le sujet en résolu
30/09/2015, 07h20
Sve@r
Citation:

Envoyé par TuxThePenguin

J'avais déjà vu la partie sur les liens symbolique et les liens physique. Saurais-tu pourquoi cette notion de lien physique n'a pas été implémenter sous les systèmes Windows
contrairement au liens symboliques faisant référence aux raccourcis sous Windows ?

Parce que la façon dont zindow gère ses fichiers n'est pas du tout la même. Unix a implémenté une gestion à 2 étapes
1. le nom du fichier fait référence à un n° d'inode (la table à 2 entrées du fichier de type "dossier")
2. le n° d'inode, qui contient toutes les caractéristiques du fichier (propriétaire, groupe, taille, type, droits, nb de liens, dates, etc) référence, lui, une adresse sur disque qui contient ses datas. En réalité il y aussi 10ko de datas directement dans l'inode pour les tout petits fichiers et le reste des datas des fichiers plus gros se trouve ailleurs accessibles par 3 adresses de différents niveaux se trouvant dans l'inode (adresse de niveau 1 référençant 1024 ko de datas, adresse de niveau 2 référençant 1024 adresses de niveau 1 et adresse de niveau 3 référençant 1024 adresses de niveau 2) mais c'est du détail
A partir de là, il est facile de rajouter deux ou 3 ou x entrées n° 1 (les liens). Cela augmente la valeur "nb liens" de l'inode. Chaque effacement (rm) va décrémenter cette valeur. Quand la valeur tombe à 0, la suite du fichier (les datas) est effacée.
Sous Zindow, je ne sais pas comment c'est implémenté mais il est clair que ce n'est pas le même mécanisme sinon ils y auraient aussi rajoutés les liens. Accessoirement les liens symboliques Unix sont apparus dans les années 90, alors qu'il aura fallu attendre NT en 94 pour voir apparaitre les raccourcis windows.

Citation:

Envoyé par TuxThePenguin

Et par curiosité si ce n'est pas indiscret, depuis quand t'intéresses-tu à l'univers unix/linux et parcours donc ce système d'exploitation ? Car tu as l'air d'avoir pas mal de connaissance sur ce domaine au niveau du fonctionnement du système d'exploitation et e sont architecture.

J'ai commencé à travailler avec en 88. J'ai vu apparaitre les premiers Linux en 98. Et je l'ai aussi enseigné en école...
30/09/2015, 07h41
Christophe

Citation:

J'avais déjà vu la partie sur les liens symbolique et les liens physique. Saurais-tu pourquoi cette notion de lien physique n'a pas été implémenter sous les systèmes Windows contrairement au liens symboliques faisant référence aux raccourcis sous Windows ?

C'est plus lié au filesystem, les premiers systèmes Windows utiisant FAT, n'implémentant rien de cela, ça a évolué avec les dernieres versions NTFS (et peut-être exFAT).

Sous Windows, tu as les raccourcis, qui sont en fait des fichiers terminés par .lnk, contenant les infos sur le fichier qu'il pointe.Le lien avec le filesystem est quand même moins fort, mais ça a ses avantages et ses inconvénients. Si tu montes une partition Windows sous Linux, les fichiers .lnk ne seront pas exploitable.

Depuis Windows 7/Vista, tu as les points de jonctions, plus proche du lien symbolique sous Linux : https://support.microsoft.com/fr-fr/kb/205524. C'est ce qui est utilisé pour faire correspondre l'ancienne dénomination avant Vista "Documents & Settings" avec Users. En usage normal sous l'interface graphique, c'est un fichier .lnk qui est crée. Les points de jonction sont peu utilisés. Une partition NTS montée sous Linux permettra le fonctionnement des points de jonction.

Avantages/inconvénients que je vois aux liens symboliques par rapport au fichier .lnk : leur sauvegarde. Les fichiers.lnk étant des fichiers normaux sont sauvegardés facilement (pour qu'ils restent fonctionnels, leur fichier source doit avoir le même chemin bien entendu, mais si celiu-ci ne l'est plus, l'interface graphique permet de rechercher le fichier source pour le corriger), contrairement aux symlinks où c'est plus délicat. Les symlinks sont plus ancrés en profondeur dans le fiesystem. Sous Windows, dans les applications, les raccourcis (.lnk) ne sont pas tout le temps fonctionnels, ils le sont totalement dans l'explorateur bien sûr.