Le 20-02-2007, Matthieu Moy <MatthieuNOSPAM.Moy@imag.fr.invalid> a écrit:
> fembe <fembe@hotmail.com> writes:
>
>> ça marche bien sauf que la date du fichier résultat n'est pas la
>> même que le fichier de départ !! comment faire ?
>
> La commande «touch» fait ça. Je suppose qu'il y a un appel système
> qui fait ça sans passer par l'executable «touch».

Oui, et en faisant un strace touch -t ..., on voit les appels
systèmes faits par touch pour faire ça.

Marc Boyer
--
Si tu peux supporter d'entendre tes paroles
Travesties par des gueux pour exciter des sots
IF -- Rudyard Kipling (Trad. André Maurois)

fembe <fembe@hotmail.com> writes:

> ça marche bien sauf que la date du fichier résultat n'est pas la
> même que le fichier de départ !! comment faire ?

La commande «touch» fait ça. Je suppose qu'il y a un appel système
qui fait ça sans passer par l'executable «touch».

--
Matthieu

bonjour,
je développe un logiciel sous linux en gcc et je dois copier des gros
fichiers du disque dur vers une clé usb à la demande de l'utilisateur,
Pour pouvoir avoir une barre de défilement et une interruption possible
par l'utilisateur,je ne peux pas utilisé la commande "cp -p" mais
j'utilise les commandes standard ( open , read write close etc...) ça
marche bien sauf que la date du fichier résultat n'est pas la même que
le fichier de départ !! comment faire ?

fembe <fembe@hotmail.com> writes:

> bonjour,
> je développe un logiciel sous linux en gcc et je dois copier des gros
> fichiers du disque dur vers une clé usb à la demande de l'utilisateur,
> Pour pouvoir avoir une barre de défilement et une interruption possible
> par l'utilisateur,je ne peux pas utilisé la commande "cp -p" mais
> j'utilise les commandes standard ( open , read write close etc...) ça
> marche bien sauf que la date du fichier résultat n'est pas la même que
> le fichier de départ !! comment faire ?

rsync --progress /gros/fichier /cle/usb/ | dessiner-barre-de-defilement

Oh! Et regarde toutes les options qu'il y a:

-H, --hard-links preserve hard links
-p, --perms preserve permissions
-o, --owner preserve owner (root only)
-g, --group preserve group
-D, --devices preserve devices (root only)
-t, --times preserve times


--
__Pascal Bourguignon__ http://www.informatimago.com/

HEALTH WARNING: Care should be taken when lifting this product,
since its mass, and thus its weight, is dependent on its velocity
relative to the user.

[ fclc supprimé des suivis, inadapté. ]

fembe écrivit dans news:pan.2007.02.20.08.41.37.18175@hotmail.com:
> je développe un logiciel sous linux en gcc et je dois copier des gros
> fichiers du disque dur vers une clé usb à la demande de l'utilisateur,
> Pour pouvoir avoir une barre de défilement et une interruption
> possible par l'utilisateur,je ne peux pas utilisé la commande "cp -p"
> mais j'utilise les commandes standard ( open , read write close
> etc...) ça marche bien sauf que la date du fichier résultat n'est pas
> la même que le fichier de départ !! comment faire ?

man utime(2)


Antoine

ok ; je vais essayer par l'appel système "touch -r"


Le Tue, 20 Feb 2007 09:24:30 +0100, Matthieu Moy a écrit:

> fembe <fembe@hotmail.com> writes:
>
>> ça marche bien sauf que la date du fichier résultat n'est pas la même
>> que le fichier de départ !! comment faire ?
>
> La commande «touch» fait ça. Je suppose qu'il y a un appel système
> qui fait ça sans passer par l'executable «touch».

fembe wrote:

> je développe un logiciel sous linux en gcc et je dois copier des gros
> fichiers du disque dur vers une clé usb à la demande de l'utilisateur,
> Pour pouvoir avoir une barre de défilement et une interruption possible
> par l'utilisateur,je ne peux pas utilisé la commande "cp -p" mais
> j'utilise les commandes standard ( open , read write close etc...) ça

Non, open, read et write ne sont pas "standard"

LinuxKiller wrote in message <erkrkq$7ih$3@gyptis.org>:
> Non, open, read et write ne sont pas "standard"

Sous Unix, si, totalement. Regarde où est crossposté cet article.

Le 22/02/07 20:42, dans <erkrkq$7ih$3@gyptis.org>, «LinuxKiller»
<linuxfucker@LinuxKiller.labas.org> a écrit:

> Non, open, read et write ne sont pas "standard"

On ne peut guère faire plus standard que l'ISO/IEC 9945-1. C'est aussi Posix
Std 1003.1. Par contre effectivement ce n'est pas ISO/IEC 9899.

--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.

Eric Levenez wrote:

>> Non, open, read et write ne sont pas "standard"

> On ne peut guère faire plus standard que l'ISO/IEC 9945-1. C'est aussi Posix
> Std 1003.1. Par contre effectivement ce n'est pas ISO/IEC 9899.

C'est bien ce que je voulais écrire

Eric Levenez écrivit dans news:C203B993.9FAD7%news@levenez.com:
>
> On ne peut guère faire plus standard que l'ISO/IEC 9945-1.

Si. ISO/CÉI 9899.

:-)


Antoine

Le 23/02/07 14:18, dans <ermpjb$vft$1@shakotay.alphanet.ch>, «Antoine
Leca» <root@localhost.invalid> a écrit:

> Eric Levenez écrivit dans news:C203B993.9FAD7%news@levenez.com:
>>
>> On ne peut guère faire plus standard que l'ISO/IEC 9945-1.
>
> Si. ISO/CÉI 9899.

Ce n'est pas plus standard, c'est juste un autre standard. N'oublie pas que
le Linux Killer disait que les fonctions citées n'était pas standard, ce qui
dans l'absolu (et vu le cross-post) était totalement faux. La même
affirmation faite uniquement sur fclc aurait été vraie, comme je l'ai
indiqué.

--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.

Eric Levenez wrote:

> Ce n'est pas plus standard, c'est juste un autre standard. N'oublie pas que
> le Linux Killer disait que les fonctions citées n'était pas standard, ce qui
> dans l'absolu (et vu le cross-post) était totalement faux. La même
> affirmation faite uniquement sur fclc aurait été vraie, comme je l'ai
> indiqué.

Le crosspost n'était pas logique. Les fonctions en question (open, read,
write) ne sont pas spécifiques à Unix*.*.

Eric Levenez écrivit dans news:C204E421.9FCA9%news@levenez.com:
> Le 23/02/07 14:18, dans <ermpjb$vft$1@shakotay.alphanet.ch>, « Antoine
> Leca » <root@localhost.invalid> a écrit :
>
>> Eric Levenez écrivit dans news:C203B993.9FAD7%news@levenez.com:
>>>
>>> On ne peut guère faire plus standard que l'ISO/IEC 9945-1.
>>
>> Si. ISO/CÉI 9899.
>
> Ce n'est pas plus standard, c'est juste un autre standard.

C'est une autre _norme_. Et c'est plus standard, au sens où c'est une norme
plus répandue, d'application réelle plus large.


> N'oublie pas que le Linux Killer disait que les fonctions citées
> n'était pas standard, ce qui dans l'absolu (et vu le cross-post)
> était totalement faux.

Je ne contredis pas ta dénégation. Bien sûr que ces fonctions sont
standards, et même le sont largement au-delà de ISO/CÉI 9945-1:1990. Elles y
sont normalisées, et cette norme (ainsi que ses prédécesseurs directs,
normes ou standards) a inspiré de nombreux autres « standards » utilisés en
programmation C; il devrait donc être complètement évident à tout le monde
que l'intervention relevait de la catégorie troll.


Antoine