Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Windows Windows Vista Discussions Générales Un bug commun à toutes les versions de Windows !!!

Un bug commun à toutes les versions de Windows !!!

21 réponses
Avatar
Geofrey van Hecke
Bonjour tout le monde,

Lorsque l'on supprime un fichier, puis que l'on recrée un autre avec
exactement le même nom que le précédent. La date de création du nouveau
fichier est pareil à celle du fichier original supprimé.

C'est en débugant un programme que j'ai rencontré cette anomalie. Mais l'on
peut facilement l'observé en faisant le test à la main via Windows Explorer
ou l'invite de commande.

J'ai refais les tests et observé le même problème sous Windows 2000 server
SP4 et Windows XP SP2.

C:\temp>dir test.txt /tc
Volume in drive C has no label.
Volume Serial Number is A828-E9B4

Directory of C:\temp

21/03/2007 08:46 16 test.txt
1 File(s) 16 bytes
0 Dir(s) 816.140.288 bytes free

C:\temp>del test.txt

C:\temp>echo .> test.txt

C:\temp>dir test.txt /tc
Volume in drive C has no label.
Volume Serial Number is A828-E9B4

Directory of C:\temp

21/03/2007 08:46 3 test.txt
1 File(s) 3 bytes
0 Dir(s) 816.140.288 bytes free
Signaler un problème avec ce contenu

10 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
1 2 3
Avatar
Richard Clark
Ben ca m'intéresse alors: quelles sont les api pour accéder à ce bit
d'archivage ?

--
Richard Clark
http://www.c2i.fr Le 1er site .NET
http://www.project-hoshimi.com
"huggy" a écrit dans le message de
news:
Bonjour

Les sauvegardes incrémentielles ne fonctionnent pas sur la date et l'heure
mais sur le bit d'archive !

Alors !

Bon courage
"Richard Clark" <rc at c2i.fr> a écrit dans le message de
news:
Ben oui ca peut être vraiment embêtant. Si ce bug est vérifié, ca peut
être même vraiment un pb.

Prenons l'exemple des sauvegardes incrémentielles, elles ne détectent pas
de modifs.

--
Richard Clark
http://www.c2i.fr Le 1er site .NET
http://www.project-hoshimi.com
"Le Claude" a écrit dans le
message de news:
Salut,


Crois-tu que cela vaille la peine de s'en inquiéter ?
Personnellement, je me soucie peu des dates de création de mes fichiers
du moment que quand je clique dessus ils s'ouvrent et fonctionnent.-:)))
--
Amicalement, Claude.

Claude CHARNEAU MVP-Shell/User.

La fé sense obras, morta es.


"Geofrey van Hecke" a écrit dans le message de
news:%
Bonjour tout le monde,

Lorsque l'on supprime un fichier, puis que l'on recrée un autre avec
exactement le même nom que le précédent. La date de création du nouveau
fichier est pareil à celle du fichier original supprimé.

C'est en débugant un programme que j'ai rencontré cette anomalie. Mais
l'on peut facilement l'observé en faisant le test à la main via Windows
Explorer ou l'invite de commande.

J'ai refais les tests et observé le même problème sous Windows 2000
server SP4 et Windows XP SP2.

C:temp>dir test.txt /tc
Volume in drive C has no label.
Volume Serial Number is A828-E9B4

Directory of C:temp

21/03/2007 08:46 16 test.txt
1 File(s) 16 bytes
0 Dir(s) 816.140.288 bytes free

C:temp>del test.txt

C:temp>echo .> test.txt

C:temp>dir test.txt /tc
Volume in drive C has no label.
Volume Serial Number is A828-E9B4

Directory of C:temp

21/03/2007 08:46 3 test.txt
1 File(s) 3 bytes
0 Dir(s) 816.140.288 bytes free












Avatar
huggy
Bonjour

La commande Attrib fait le nécessaire, mais en WSH ou en PowerShell, ou en
WMI, les api existent. Je ne suis pas programmeur, mais je les ai déjà vu.
Sinon dirctement bouton droit sur le fichier, propriétés, avancé, attributs
avancées, attribut de fichier, le fichier est pret à être archivé ...

Bon courage

"Richard Clark" <rc at c2i.fr> a écrit dans le message de
news:
Ben ca m'intéresse alors: quelles sont les api pour accéder à ce bit
d'archivage ?

--
Richard Clark
http://www.c2i.fr Le 1er site .NET
http://www.project-hoshimi.com
"huggy" a écrit dans le message de
news:
Bonjour

Les sauvegardes incrémentielles ne fonctionnent pas sur la date et
l'heure mais sur le bit d'archive !

Alors !

Bon courage
"Richard Clark" <rc at c2i.fr> a écrit dans le message de
news:
Ben oui ca peut être vraiment embêtant. Si ce bug est vérifié, ca peut
être même vraiment un pb.

Prenons l'exemple des sauvegardes incrémentielles, elles ne détectent
pas de modifs.

--
Richard Clark
http://www.c2i.fr Le 1er site .NET
http://www.project-hoshimi.com
"Le Claude" a écrit dans le
message de news:
Salut,


Crois-tu que cela vaille la peine de s'en inquiéter ?
Personnellement, je me soucie peu des dates de création de mes fichiers
du moment que quand je clique dessus ils s'ouvrent et
fonctionnent.-:)))
--
Amicalement, Claude.

Claude CHARNEAU MVP-Shell/User.

La fé sense obras, morta es.


"Geofrey van Hecke" a écrit dans le message de
news:%
Bonjour tout le monde,

Lorsque l'on supprime un fichier, puis que l'on recrée un autre avec
exactement le même nom que le précédent. La date de création du
nouveau fichier est pareil à celle du fichier original supprimé.

C'est en débugant un programme que j'ai rencontré cette anomalie. Mais
l'on peut facilement l'observé en faisant le test à la main via
Windows Explorer ou l'invite de commande.

J'ai refais les tests et observé le même problème sous Windows 2000
server SP4 et Windows XP SP2.

C:temp>dir test.txt /tc
Volume in drive C has no label.
Volume Serial Number is A828-E9B4

Directory of C:temp

21/03/2007 08:46 16 test.txt
1 File(s) 16 bytes
0 Dir(s) 816.140.288 bytes free

C:temp>del test.txt

C:temp>echo .> test.txt

C:temp>dir test.txt /tc
Volume in drive C has no label.
Volume Serial Number is A828-E9B4

Directory of C:temp

21/03/2007 08:46 3 test.txt
1 File(s) 3 bytes
0 Dir(s) 816.140.288 bytes free















Avatar
Jean-Claude BELLAMY
"Richard Clark" <rc at c2i.fr> a écrit dans le message de
news:
Ben ca m'intéresse alors: quelles sont les api pour accéder à ce bit
d'archivage ?


"GetFileAttributesEx"
http://msdn2.microsoft.com/en-gb/library/aa364946.aspx
BOOL GetFileAttributesEx(
LPCTSTR lpFileName,
GET_FILEEX_INFO_LEVELS fInfoLevelId,
LPVOID lpFileInformation
);

qui utilise une structure "WIN32_FILE_ATTRIBUTE_DATA"
http://msdn2.microsoft.com/en-gb/library/aa365739.aspx
typedef struct _WIN32_FILE_ATTRIBUTE_DATA {
DWORD dwFileAttributes;
FILETIME ftCreationTime;
FILETIME ftLastAccessTime;
FILETIME ftLastWriteTime;
DWORD nFileSizeHigh;
DWORD nFileSizeLow;
} WIN32_FILE_ATTRIBUTE_DATA,
*LPWIN32_FILE_ATTRIBUTE_DATA;

le DWORD "dwFileAttributes" contient les attributs du fichier, p.ex.
FILE_ATTRIBUTE_ARCHIVE, qu'il suffit de tester.


Il existe aussi la fonction "GetFileAttributes"
http://msdn2.microsoft.com/en-gb/library/aa364944.aspx
DWORD GetFileAttributes(
LPCTSTR lpFileName
);
mais elle ne donne que les attributs du fichier (GetFileAttributesEx donne
en plus les dates de création, accès, écriture et la taille du fichier)

Tu as un exemple ici :
http://msdn2.microsoft.com/en-gb/library/aa365522.aspx


--
May the Force be with You!
La Connaissance s'accroît quand on la partage
----------------------------------------------------------
Jean-Claude BELLAMY [MVP]
http://www.bellamyjc.org ou http://jc.bellamy.free.fr

Avatar
Nina Popravka
On Wed, 21 Mar 2007 13:04:08 +0100, mdnews
wrote:

sauvegarde "tordus" alors que ce système d'attribut archive fonctionne
remarquablement bien.


Tu tombes bien, et tu risques de me faire gagner du temps :-)
Est-ce que rsync l'utilise ?
--
Nina

Avatar
huggy
Bonjour

"mdnews" a écrit dans le message de
news:
Wed, 21 Mar 2007 12:05:53 +0100, "Richard Clark" <rc at c2i.fr> >>

Ben ca m'intéresse alors: quelles sont les api pour accéder à ce bit
d'archivage ?



Sans aller chercher jusqu'au niveau API, il existe plusieurs commandes
"DOS" qui utilisent cet attribut "Archive"

XCOPY par exemple:
/A Copie uniquement les fichiers ayant l'attribut archive,
ne modifie pas l'attribut.
/M Copie uniquement les fichiers ayant l'attribut archive,
désactive l'attribut archive.

En jouant simplement sur cet attribut et en l'effacant ou pas on fait
des batchs de backups complets/différentiel/incrémental.
NTBackup s'en sert aussi, de même que la plupart des outils de
compression.

Niveau programmation, ça se gère exactement comme les autres attributs
de base (Read Only, System, Hidden, Archive)

C'est fou ce qu'on a tendance à parfois faire des systèmes de
sauvegarde "tordus" alors que ce système d'attribut archive fonctionne
remarquablement bien. Dès qu'un fichier est nouveau ou modifié il
reprend automatiquement son attribut "à Archiver"


Et oui ! Nous aimons refaire ce qui existe déjà ! En plus compliqué pour
créer de nouveaux spécialistes indispensables !


Avatar
Faelan
"Jean-Claude BELLAMY" a écrit dans le
message de news:

"Geofrey van Hecke" a écrit dans le message de
news:%
Bonjour tout le monde,

Lorsque l'on supprime un fichier, puis que l'on recrée un autre avec
exactement le même nom que le précédent. La date de création du nouveau
fichier est pareil à celle du fichier original supprimé.



It's not a bug, it's by design !!!!

http://msdn2.microsoft.com/en-gb/library/ms724320.aspx

"If you rename or delete a file, then restore it
shortly thereafter, Windows searches the cache
for file information to restore.
Cached information includes its short/long name
pair and creation time."

Seule la date de création est conservée, et non pas les dates de dernier
accès ou dernière écriture (heureusement!)


Personnellement, je trouve que restaurer un fichier détruit ou en créer un
nouveau avec le même nom, ce n'est pas pareil.
Mais bon, je suppose que mon opinion n'est pas la bonne ... ;)

--

F.


Avatar
Geofrey van Hecke
Perso, la seul justification que je peux admettre derrière cela est
effectivement lorsqu'il s'agit de restaurer un fichier qui aurait été
supprimé par mégarde ou corrompu... Mais pas lorsqu'il s'agit de remplacer
un fichier par un autre portant le même nom !!!



"Jean-Claude BELLAMY" wrote in message
news:
"Geofrey van Hecke" a écrit dans le message de
news:%
Bonjour tout le monde,

Lorsque l'on supprime un fichier, puis que l'on recrée un autre avec
exactement le même nom que le précédent. La date de création du nouveau
fichier est pareil à celle du fichier original supprimé.



It's not a bug, it's by design !!!!

http://msdn2.microsoft.com/en-gb/library/ms724320.aspx

"If you rename or delete a file, then restore it
shortly thereafter, Windows searches the cache
for file information to restore.
Cached information includes its short/long name
pair and creation time."

Seule la date de création est conservée, et non pas les dates de dernier
accès ou dernière écriture (heureusement!)


--
May the Force be with You!
La Connaissance s'accroît quand on la partage
----------------------------------------------------------
Jean-Claude BELLAMY [MVP]
http://www.bellamyjc.org ou http://jc.bellamy.free.fr



Avatar
Jean-Claude BELLAMY
"Faelan" a écrit dans le message de
news:u$
"Jean-Claude BELLAMY" a écrit dans le
message de news:
"Geofrey van Hecke" a écrit dans le message de
news:%
Lorsque l'on supprime un fichier, puis que l'on recrée un autre avec
exactement le même nom que le précédent. La date de création du nouveau
fichier est pareil à celle du fichier original supprimé.


It's not a bug, it's by design !!!!

http://msdn2.microsoft.com/en-gb/library/ms724320.aspx

"If you rename or delete a file, then restore it
shortly thereafter, Windows searches the cache
for file information to restore.
Cached information includes its short/long name
pair and creation time."

Seule la date de création est conservée, et non pas les dates de dernier
accès ou dernière écriture (heureusement!)


Personnellement, je trouve que restaurer un fichier détruit ou en créer un
nouveau avec le même nom, ce n'est pas pareil.
Mais bon, je suppose que mon opinion n'est pas la bonne ... ;)


En ce qui me concerne, je n'ai fait que retrouver l'info de Microsoft qui
prouve que ce n'est pas un bug, mais au contraire que c'est volontaire de la
part de MS. Et comme ce n'est pas un bug, il est donc inutile de s'esbaudir
devant ce fait ou de chercher quelle erreur on aurait pu commettre!

C'est comme sous XP HOME l'anonymisation des connexions entrantes ...

Par contre savoir si c'est "bien" ou "mal", c'est un autre problème.

Et quand tu dis
"restaurer un fichier détruit ou en créer un
nouveau avec le même nom, ce n'est pas pareil"
pour toi humain, OUI, mais pour l'OS et le FS, c'est la même chose !

Comme quoi un utilisateur et son système d'exploitation, c'est comme dans la
pub pour une marque de rillettes :
"Nous n'avons pas les mêmes valeurs !"
;-)


--
May the Force be with You!
La Connaissance s'accroît quand on la partage
----------------------------------------------------------
Jean-Claude BELLAMY [MVP]
http://www.bellamyjc.org ou http://jc.bellamy.free.fr



Avatar
Faelan
"Jean-Claude BELLAMY" a écrit dans le
message de news:

Personnellement, je trouve que restaurer un fichier détruit ou en créer
un nouveau avec le même nom, ce n'est pas pareil.
Mais bon, je suppose que mon opinion n'est pas la bonne ... ;)


En ce qui me concerne, je n'ai fait que retrouver l'info de Microsoft qui
prouve que ce n'est pas un bug, mais au contraire que c'est volontaire de
la part de MS. Et comme ce n'est pas un bug, il est donc inutile de
s'esbaudir devant ce fait ou de chercher quelle erreur on aurait pu
commettre!

C'est comme sous XP HOME l'anonymisation des connexions entrantes ...

Par contre savoir si c'est "bien" ou "mal", c'est un autre problème.

Et quand tu dis
"restaurer un fichier détruit ou en créer un
nouveau avec le même nom, ce n'est pas pareil"
pour toi humain, OUI, mais pour l'OS et le FS, c'est la même chose !


L'OS et le FS font ce qui est programmé.
Et personnellement, je trouve que ça se justifie pour le restore mais pas
pour un nouveau fichier créé portant le même nom. Le second cas est-il
vraiment voulu ou est-ce une conséquence accidentelle ?
Nous n'avons pas toujours les mêmes valeurs que Microsoft, en tout cas ;))

Mais bon, ça ne sert à rien de polémiquer, c'est comme ça :)

--
F.


Avatar
Geofrey van Hecke
Pour info, Linux semble avoir complètement résolu ce problème en ne
sauvegardant aucune date de création sur les fichiers et dossiers... Il y a
bien des date de modification et d'accès qui sont tenus à jour mais pas de
date de création.


"Faelan" wrote in message
news:%23NlApP$
"Jean-Claude BELLAMY" a écrit dans le
message de news:

Personnellement, je trouve que restaurer un fichier détruit ou en créer
un nouveau avec le même nom, ce n'est pas pareil.
Mais bon, je suppose que mon opinion n'est pas la bonne ... ;)


En ce qui me concerne, je n'ai fait que retrouver l'info de Microsoft qui
prouve que ce n'est pas un bug, mais au contraire que c'est volontaire de
la part de MS. Et comme ce n'est pas un bug, il est donc inutile de
s'esbaudir devant ce fait ou de chercher quelle erreur on aurait pu
commettre!

C'est comme sous XP HOME l'anonymisation des connexions entrantes ...

Par contre savoir si c'est "bien" ou "mal", c'est un autre problème.

Et quand tu dis
"restaurer un fichier détruit ou en créer un
nouveau avec le même nom, ce n'est pas pareil"
pour toi humain, OUI, mais pour l'OS et le FS, c'est la même chose !


L'OS et le FS font ce qui est programmé.
Et personnellement, je trouve que ça se justifie pour le restore mais pas
pour un nouveau fichier créé portant le même nom. Le second cas est-il
vraiment voulu ou est-ce une conséquence accidentelle ?
Nous n'avons pas toujours les mêmes valeurs que Microsoft, en tout cas ;))

Mais bon, ça ne sert à rien de polémiquer, c'est comme ça :)

--
F.





1 2 3