Sinon, si le fichier cible et destination ne sont pas sur le même support physique, ou si ce support physique est distant, il sera probablement plus rapide de lire et écrire simultanément avec un buffer tournant. (à l'inverse, ça ralentira probablement les copies sur le même support physique local donc il faut détecter quelle variante utiliser). O_NONBLOCK est ton ami pour ça, mais c'est autrement plus compliqué à implémenter.
Et puis en fonctionnalités après, comme dit plus haut une copie complète va copier aussi les métadonnées. Et là c'est compliqué parce que dépendant de l'OS et même du système de fichier.
- fichiers à trous : sous Linux 3.1 et+ tu peux utiliser lseek pour ça ou un ioctl FIEMAP.
- fichiers spéciaux : fstat → mknod, mkfifo (à la limite, sans les gérer, au moins les détecter pour les sauter)
- symlink : readlink, symlink (idéalement une option pour copier soit le lien soit le fichier cible - proposer aussi d'ajuster les symlinks relatifs pour qu'ils restent valides)
- dates : fstat → utime
- permissions : fstat → fchmod
- owner : fstat → fchown, lchown
- attributs fs : ioctl FS_IOC_GETFLAGS → ioctl FS_IOC_SETFLAGS
- attributes étendus : fgetxattr → fsetxattr
- ACL : acl_get_fd → acl_set_fd (ou fgetxattr → fsetxattr pour les guerriers)
Pour faire les choses bien, tu devrais :
- Faire attention aux race conditions (le même nom de fichier peut pointer sur un autre fichier s'il se fait écraser entre deux appels, pour ça on utilise les variantes f* des appels, qui prennent un descripteur de fichier et pas un nom).
- Obtenir un lock sur le fichier (flock). Histoire de collaborer avec les applis qui les utilisent.
Si ton but c'était la libc, c'est pas tellement pertinent. Mais si c'était pour jouer avec les fichiers en général, y'a de la matière
