Discussion :

[wamkey]

Bonjour,

je suis confronté à un problème épineux.
Je gère un serveur (2008 server) + Exchange server 2010
Nos données sont installées sur un disque dont un dossier est partagé.

Depuis quelques temps, je constate que par moment, tous les fichiers qui atterrissent d'une manière ou d'une autre sur ce dossier partagé prennent la date et l'heure du moment de cet "atterrissage".

Par atterrissage, j'entends évidemment les fichiers nouvellement créés, mais surtout, et c'est là mon problème, les fichiers déplacés, copiés/collés ou extraits d'archives compressées.
Donc concrètement, si dans un dossier (ou une archive zip) quelconque, j'ai un fichier qui a été créé le 15/04/2009 et que je décide aujourd’hui de déplacer ou copier/coller (ou décompresser) ce fichier quelque part sur mon dossier, automatiquement, ses dates de modification et de création seront celles d'aujourd'hui au lieu du 15/04/2009.

IMPORTANT:
Lorsque je me connecte au serveur avec un client, je n'ai pas ce problème... bizarre!
Le plus souvent, j'interviens sur ce serveur en bureau à distance ou avec Teamviewer. Le problème est le même, que je contrôle le serveur avec l'une ou l'autre des 2 solutions.
Ce problème semble être lié à un autre phénomène que nous avons constaté qui est le blocage temporaire des actions sur certains répertoires après des déplacements. Le fichier Thumbs.db semble empêcher la moindre modification, comme la suppression ou le renommage d'un répertoire pendant un certain temps.
En revenant quelques minutes ou quelques heures plus tard sur le même répertoire, tout redevient normal. Les fichiers se créent à la bonne date, je peux de nouveau renommer le répertoire ou le supprimer sans encombre...
Bref, je suis un peu perdu...

Une bonne âme pour m'aider?

[wamkey]

Bonjour,

je suis confronté à un problème épineux.
Je gère un serveur (2008 server) + Exchange server 2010
Nos données sont installées sur un disque dont un dossier est partagé.

Depuis quelques temps, je constate que par moment, tous les fichiers qui atterrissent d'une manière ou d'une autre sur ce dossier partagé prennent la date et l'heure du moment de cet "atterrissage".

Par atterrissage, j'entends évidemment les fichiers nouvellement créés, mais surtout, et c'est là mon problème, les fichiers déplacés, copiés/collés ou extraits d'archives compressées.
Donc concrètement, si dans un dossier (ou une archive zip) quelconque, j'ai un fichier qui a été créé le 15/04/2009 et que je décide aujourd’hui de déplacer ou copier/coller (ou décompresser) ce fichier quelque part sur mon dossier, automatiquement, ses dates de modification et de création seront celles d'aujourd'hui au lieu du 15/04/2009.

IMPORTANT:
Lorsque je me connecte au serveur avec un client, je n'ai pas ce problème... bizarre!
Le plus souvent, j'interviens sur ce serveur en bureau à distance ou avec Teamviewer. Le problème est le même, que je contrôle le serveur avec l'une ou l'autre des 2 solutions.
Ce problème semble être lié à un autre phénomène que nous avons constaté qui est le blocage temporaire des actions sur certains répertoires après des déplacements. Le fichier Thumbs.db semble empêcher la moindre modification, comme la suppression ou le renommage d'un répertoire pendant un certain temps.
En revenant quelques minutes ou quelques heures plus tard sur le même répertoire, tout redevient normal. Les fichiers se créent à la bonne date, je peux de nouveau renommer le répertoire ou le supprimer sans encombre...
Bref, je suis un peu perdu...

Une bonne âme pour m'aider?

Même pas une petite idée???

[Jipété]

Ce problème semble être lié à un autre phénomène que nous avons constaté qui est le blocage temporaire des actions sur certains répertoires après des déplacements. Le fichier Thumbs.db semble empêcher la moindre modification, comme la suppression ou le renommage d'un répertoire pendant un certain temps.
En revenant quelques minutes ou quelques heures plus tard sur le même répertoire, tout redevient normal. Les fichiers se créent à la bonne date, je peux de nouveau renommer le répertoire ou le supprimer sans encombre...

Donc effectivement il suffirait d'attendre que Thumbs.db soit libéré pour que tout fonctionne normalement, c'est bien ça ? Auquel cas tu nous as décrit le problème à l'envers, on dirait.
Pas bien grave si on trouve la solution mais pour ça, il nous manque une info capitale : quel est le contenu des dossiers en question ? Des images ?

Car il faut savoir que ce Thumbs.db est utilisé pour stocker les miniatures affichées par l'Explorateur des fichiers images : si tu fais des manipulations sur ces dossiers et/ou fichiers, il faut laisser au système le temps de faire la màj du Thumbs.

Juste une piste, car Thumbs est peut-être utilisé pour autre chose et ça fait bien longtemps que j'ai quitté le monde Windows.

[wamkey]

Je viens de faire un pas en avant dans ma problématique. Pour les fichiers thumbs, j'avais effectivement un certain pressentiment sur ce que tu dis. Mais ce que j'ai du mal à comprendre, c'est le temps qu'il faut à Windows pour mettre à jour le fichier. Il nous faut parfois attendre plusieurs minutes.

En revanche, j'ai trouvé ce qui provoquait mon problème sur la gestion des dates. Il s'agit d'un problème lié aux autorisations sur les dossiers. J'ai remarqué en fait que notre problème se produisait sur certains dossiers et pas d'autres. Il se trouve que j'avais récemment modifié certains droits sur quelques dossiers, et que c'est justement sur ces dossiers que le problème avait lieu. En faisant hériter les droits du dossier de niveau supérieur, j'ai récupéré des droits qui permettent d'éviter ce changement de date. Il me reste donc à comprendre lequel de ces droits (autorisation) fait que la date est respectée ou modifiée...

Affaire à suivre donc

[wamkey]

Bon, et bien mon problème n'est pas totalement résolu s'agissant de la gestion des dates, et j'ai vraiment besoin d'aide car sinon, je vais devenir fou avec cette histoire. Voici donc une description précise du problème.

Nos données sont installées sur une partie d'un disque et partagées sur le réseau. J'ai créé un lecteur réseau Z:\.
Le chemin réel du dossier est E:\DATA.

Supposons que j'ai sur le bureau du serveur un fichier dont la date de modification est le 14/01/2005.

• Si je copie ou déplace ce fichier vers E:\DATA, il conserve sa date de modification.
• Si je copie ou déplace ce fichier vers Z:\, qui correspond pourtant en tout point au même répertoire, la date de modification du fichier est modifiée et prend la date du jour où j'effectue cette opération.Peu importe où le fichier d'origine se trouve.

Pire, récemment, je me suis même rendu compte que lorsque je décompressais une archive (zip ou autre), les dates des fichiers qui s'installaient sur mon répertoire (donc décompressés) prenaient eux aussi la date du jour.

Alors que normalement, lors d'une telle opération, la date du fichier devrait être celle du fichier contenu dans l'archive.

C'est totalement ubuesque. J'imagine qu'il y a une raison logique là derrière...et j'aimerais bien comprendre laquelle.

Voici la vidéo qui montre et explique tout.

Merci d'avance pour votre aide.

[Jipété]

Nos données sont installées sur une partie d'un disque et partagées sur le réseau. J'ai créé un lecteur réseau Z:\.
Le chemin réel du dossier est E:\DATA.

Supposons que j'ai sur le bureau du serveur un fichier dont la date de modification est le 14/01/2005.

• Si je copie ou déplace ce fichier vers E:\DATA, il conserve sa date de modification.
• Si je copie ou déplace ce fichier vers Z:\, qui correspond pourtant en tout point au même répertoire, la date de modification du fichier est modifiée et prend la date du jour où j'effectue cette opération. Peu importe où le fichier d'origine se trouve.

Non !
Pour toi, oui, car tu fais abstraction des notions sophistiquées concernant le montage et le mappage de ton lecteur réseau vers la lettre "Z:".
Mais pour la machine, c'est complètement différent.

Je prends une image : tu es en train de récupérer des pelletées de terre dans ton jardin pour les balancer dans la brouette à côté de toi. Bien.
Tu peux aussi prendre tes pelletées de terre et partir avec la pelle chargée à bloc pour faire le tour de la maison et attaquer la brouette par l'autre côté pour au final y vider ta pelle.
Pour la brouette c'est pareil (aux pertes liées au transport près), pour toi non, le soir tu auras les jambes en coton.

Bref, tout ça pour dire qu'en passant par le réseau tu perds les informations du premier fichier car tu en crées un nouveau et voilà.
C'est exactement comme si tu avais mappé une lettre: vers un dossier partagé d'un disque installé dans une machine à l'autre bout du monde : vu de ta machine, dans ton poste de travail tu auras une nouvelle lettre de lecteur, si tu y copies un fichier il va se trimballer à travers le réseau jusqu'à l'autre machine où il est inconnu, donc date de création = l'instant où la copie se lance (ou se termine, fais un test).

Pour l'histoire des archives, ça doit plus ou moins être le même cinéma.

[10_GOTO_10]

ses dates de modification et de création seront celles d'aujourd'hui au lieu du 15/04/2009.

Le fichier Thumbs.db semble empêcher la moindre modification, comme la suppression ou le renommage d'un répertoire pendant un certain temps.

Tout laisse à penser qu'il y a donc un traitement sur ces fichiers, quelle que soit l'extension et le type du fichier. Je ne vois pas beaucoup de causes possibles :

- Un anti-virus exotique qui modifierait la date du fichier. J'ai jamais vu ça, mais en informatique on voit parfois des choses impensables...
- Un système de chiffrage automatique, comme EFS par exemple (Encrypted File System) ?

Sinon, il faut envisager peut-être l'action d'un programme malveillant (logiciel espion ou rançongiciel). Le fait que ça se produise sur un dossier partagé est peut-être une piste. Commence par vérifier les dernières saloperies en date (Wanacry et autre). Essaye de booter sur un CD linux pour voir à quoi ressemblent réellement tes fichiers sur disque, indépendamment du système et des programmes installés. Ouvres-les si c'est des fichiers texte, fais un MD5, un diff entre les fichiers initiaux et les fichiers dont la date a changé, ce genre de choses.

Et fais des sauvegardes des fichiers non modifiés tant qu'il est encore temps, on ne sait jamais.

[transgohan]

Non !
Pour toi, oui, car tu fais abstraction des notions sophistiquées concernant le montage et le mappage de ton lecteur réseau vers la lettre "Z:".
Mais pour la machine, c'est complètement différent.

Je prends une image : tu es en train de récupérer des pelletées de terre dans ton jardin pour les balancer dans la brouette à côté de toi. Bien.
Tu peux aussi prendre tes pelletées de terre et partir avec la pelle chargée à bloc pour faire le tour de la maison et attaquer la brouette par l'autre côté pour au final y vider ta pelle.
Pour la brouette c'est pareil (aux pertes liées au transport près), pour toi non, le soir tu auras les jambes en coton.

Bref, tout ça pour dire qu'en passant par le réseau tu perds les informations du premier fichier car tu en crées un nouveau et voilà.
C'est exactement comme si tu avais mappé une lettre: vers un dossier partagé d'un disque installé dans une machine à l'autre bout du monde : vu de ta machine, dans ton poste de travail tu auras une nouvelle lettre de lecteur, si tu y copies un fichier il va se trimballer à travers le réseau jusqu'à l'autre machine où il est inconnu, donc date de création = l'instant où la copie se lance (ou se termine, fais un test).

Pour l'histoire des archives, ça doit plus ou moins être le même cinéma.

J'avoue avoir un peu de mal à croire à cette explication.
Si tu télécharges une archive sur un site internet et que tu la décompresses sur ton disque dur tu obtiendras les fichiers décompressés avec leur date d'origine et non du jour.

[Jipété]

J'avoue avoir un peu de mal à croire à cette explication.

C'était trop tôt, j'devais pas être bien réveillé, ou

Si tu télécharges une archive sur un site internet et que tu la décompresses sur ton disque dur tu obtiendras les fichiers décompressés avec leur date d'origine et non du jour.

je me suis fait des nœuds dans la tête avec l'affaire ubuesque de la date de création postérieure à la date de modif :


exemple avec un des fichiers présents dans l'archive disk2vhd.zip qui traîne qqpart, et décompressée à l'instant

[wamkey]

D'abord, un gros merci de vous intéresser à mon cas. Mon problème, en fait, n'est pas celui de la date de création. Même si, normalement, lorsqu'on décompresse un fichier, il doit théoriquement apparaître sur le disque avec ses dates de création et de modification telles qu'elles apparaissaient dans l'archive.

Mettons que je perde la date de création parce qu'on change de lecteur (supposition de Jipété), il n'y a pas raison pour que la date de modification soit altérée.
Deuxièmement, la question est: Pourquoi ce problème se produit-il sur le dossier partagé et par sur le disque sur lequel se situe le dossier en question?

Je soupçonne fortement que les droits sur les dossiers (autorisations, propriété,etc.) sont la cause. Est-ce possible? Les sous-répertoires héritant des propriétés du dossier DATA, je pense que c'est dans ces propriétés que se trouve la source de mes soucis...
Ce problème n'existait pas auparavant, et il n'est pas impossible que j'ai fait une boulette à un moment ou à un autre en gérant les paramètres de sécurité...

Je me demande si au final, je ne devrais pas tout simplement

1. réinitialiser complètement les droits sur ce dossier DATA en récupérant les autorisations du disque E
2. Vérifier si le problème disparait
3. réaffecter à chaque utilisateur de nouveaux droits précis.

Verriez-vous une solution pour vérifier mon hypothèse sans en arriver là?

[wamkey]

Alors pour ceux qui pourraient être amenés à rencontrer la même difficulté que moi, j'ai fini par identifier que le problème venait de la gestion des autorisations. Sans doute y avait-il quelque part des autorisations contradictoires ou disons plutôt que c'était un peu le bordel.

J'ai remis tous les compteurs à zéro et réaffecté les autorisations proprement à tous les utilisateurs sur tous les répertoires. Tous mes problèmes semblent avoir disparu.

Merci pour votre contribution.