- Status Nouveau
- Percent Complete
- Task Type Anomalie
- Category Freebox OS
- Assigned To No-one
- Operating System Freebox Server V7 (Delta)
- Severity High
- Priority Very Low
- Reported Version 4.9.1
- Due in Version Undecided
-
Due Date
Undecided
-
Votes
6
- yetanotherlogin (09/06/2025)
- mcorb (04/06/2025)
- Captain_Ltd (04/05/2025)
- freewhynot (24/04/2025)
- jazmac2k (13/04/2025)
- Padrys (06/04/2025)
- Private
Attached to Project: Freebox Server (Ultra V9/ Pop V8/ Delta V7 / Revolution V6 / Mini 4K)
Opened by HPie - 06/04/2025
Last edited by HPie - 10/04/2025
Opened by HPie - 06/04/2025
Last edited by HPie - 10/04/2025
FS#40205 - Modification/Suppression des dates du fichier copié sur pc (4.91/4.92)
Bonjour,
En copiant un fichier de la delta sur le pc (Windows):
1. La date de création du fichier est modifiée –> date actuelle
2. La date de modification du fichier est supprimée –> 01/01/1970
Loading...
Available keyboard shortcuts
- Alt + ⇧ Shift + l Login Dialog / Logout
- Alt + ⇧ Shift + a Add new task
- Alt + ⇧ Shift + m My searches
- Alt + ⇧ Shift + t focus taskid search
Tasklist
- o open selected task
- j move cursor down
- k move cursor up
Task Details
- n Next task
- p Previous task
- Alt + ⇧ Shift + e ↵ Enter Edit this task
- Alt + ⇧ Shift + w watch task
- Alt + ⇧ Shift + y Close Task
Task Editing
- Alt + ⇧ Shift + s save task
Constaté aussi, j'avais la flemme d'ouvrir une tâche :p
Bonjour
Je ne constate pas ce phénomène avec cifs-utils 7.0:
Les timestamps dépendent des attributs de copie:
Freebox montée sur: /mnt/FBX24T
Fichier 'toto' créé il y a quelque jours sur le share de la Freebox
Simple copie ⇒ nouveau fichier créé à la date d'aujourd'hui
copie en préservant les arguments comme le timestamp:
Lors de cette seconde copie, on voit que les informations sont préservées.
Un souci côté Windows ?
Cordialement
nbanba
Un simple copié collé de fichier permet de le voir, sous W11 en tout cas.
Uniquement dans le sens Freebox vers PC, la date de modification devient 01/01/1970 01:00:00.
Pour tester, archiver un fichier en 7z avec FreeboxOS, copier cette archive sur PC et l'ouvrir permet de voir les bonnes dates.
C'est donc bien le sens Freebox → W11 qui pose problème.
Bonjour
Ok donc si j'ai bien lu et compris vos différents postes et retours, c'est visiblement un problème uniquement "Microsoft Windows 10/11 related"… et donc pas forcément dû à la freebox
Avez vous également ouvert un ticket au support Microsoft pour ce problème ? Windows c'est payant ⇒ il doit bien avoir du support avec la licence, non ?? Sinon je ne vois pas trop pour quoi ce serait payant… (Ouvrez un ticket pour: "Lost of timestamp when copying files from ksmbd share to Windows 10/11 systems but it's working fine under Linux with cifs-tools 7.0")
Aussi ces derniers temps j'ai vu beaucoup d'échange sur linux-cifs@vger.kernel.org et d'autres LKLM concernant la préservation des ACL, etc. sur les share SMB depuis que c'est 'netfs' qui est le wrapper IO pour les shares SMB (starting at linux-6.10).
Je ne sais pas quelle est la version kernel de FreeboxOS 4.9.1 mais si c'est 6.10 ou une version supérieure (mainline 6.14 (-NOrc); actual stable: Linux-6.13.9), le souci est peut-être lié et il y a eu beaucoup d'activité sur KSMBD depuis 4 mois…
Cordialement
nbanba
Bonjour
Pour info ce que je recommande dans mon dernier message vient du fait que lors d'une copie realisée sous Linux en préservant les attributs du fichier comme dans mon poste ici: https://dev.freebox.fr/bugs/task/40205#comment188531
On constate que les timestamp sont conservés DONC ils ont étés transmis correctement avec le fichier (=le fichier provenant du share freebox est "clean", le share Freebox a transmis le fichier tel que demandé et sans erreurs).
Il semble possible (probable?) que ce soit l'OS local de la machine (ie: Windows) qui ne fasse pas son travail correctement et qui "reset" le timestamp du fichier à "epoch 0".
C'est pourquoi je recommande de voir également avec l'éditeur de l'OS de votre PC pour ce bug.
Après si vous le souhaitez il est possible de faire une étude plus approfondie de ce qu'il se passe sur votre pc, par exemple en commençant par dump les paquets SMB et par capturer les paquets correspondant au fichier lors de son transfert pour en examiner les timestamps (=timestamp du fichier a son arrivée par le réseau avant d'être "traité" localement par l'OS) afin de vérifier s'ils sont altérés ou non.
Cordialement
nbanba
J'ai encore W10.
La dernière mise à jour publiée et installée le 24 mars 2025.
Pas de problème de timestamp.
Mis à jour de la Freebox le 31 mars 2025 puis problème.
Bonjour
@mmakassikis:
J'ai poussé les tests et il semble que la date de dernière écriture et la date de dernier changement soient altérés lors du transfert SMB et reset à epoch 0
Sous Linux, les attributs sont remplacés par la dernière date d'accès.
Visiblement sous Wndows ce n'est pas le cas
Voir la capture de paquets réseau faite montrant l'altération de ces 2 dates (lien valable 30j)
https://transfert.free.fr/zQ6qfZ1
@HPie @Padrys:
Désolé, certaines des dates du fichier sont bien transmises par la Freebox avec comme valeur epoch 0
Cordialement
nbanba
@mmakassikis: Pourriez-vous jeter un œil svp ?
Bonsoir.
2 remarques :
Bonjour,
À peu près le même constat sur mes 2 PC sous Windows 11 24H2, au moins depuis la MAJ 4.9.1.
Quand les fichiers sont copiés/collés du server Mini4K vers l'un ou l'autre des PC, dossiers "Téléchargement", ils ne comportent aucune date.
Quand le bug est apparu, j'ai cru un moment que les fichiers n'étaient pas copiés, ou qu'ils avaient disparu.
Il a fallu que je déplace la souris tout en bas du dossier "Téléchargements" du PC pour les retrouver, dans le sous-dossier "Non spécifié(e)", colonne "Modifié le" vide.
Une des corrections effectuées pour la version 4.91 : Erreur de copie SMB depuis Windows (
FS#40129)Je voudrais bien savoir quelle était cette erreur de copie et si cette correction provoque en fin de compte ce bug de la date.
«Je voudrais bien savoir quelle était cette erreur de copie»
L'auteur de la tâche
FS#129décrit très bien l'erreur de copie qui a été corrigée par la MAJ 4.9.1. :«Depuis la mise à jour 4.9.0, lorsque je copie un fichier vidéo (mp4, mkv etc) depuis mon ordinateur vers le disque dur de la freebox via l”explorateur de fichier windows donc via le réseau local, le fichier se copie bien (par exemple plusieurs minutes pour 1 fichier de 1,2 go) mais ensuite se retrouve avec une taille de 1 kilo.»
https://dev.freebox.fr/bugs/task/40129
«…et si cette correction provoque en fin de compte ce bug de la date.»
La MAJ 4.9.1. est intervenue le 26 mars, la MAJ suivante (la 4.9.2.) n'est intervenue que le 10 avril et nous, les utilisateurs, nous avons constaté ces bugs de date bien avant le 10 avril.
https://dev.freebox.fr/blog/
Il y a donc de très fortes chances que c'est bien la MAJ 4.9.1. qui a provoqué ce dommaj collatéral. :)
une copie de fichier depuis windows 11 vers soit la freebox, soit un server samba 4.20 a le comportement que vous décrivez; la date de dernière modification est le 01/01/1970.
le comportement est exactement le même quand je crée un partage dans la VM windows 11, et refait le test (donc W11 qui parle à W11 en SMB).
en faisant une capture, le client envoie une requête SetInfo pour mettre à jour les métadonnées:
https://imgur.com/a/dE2dyTx
cela semble donc être un bug dans le client SMB de windows (test fait sur W11 Pro 24h2 26100.3775)
Bonjour
Merci pour votre retour.
Comment expliquer cependant que je constate la même chose sous Linux ?
En fait comment expliquer que le serveur renvoi des dates à epoch 0 ?
https://imgur.com/a/775wLLA
C'est peut-être plus profond que ça… voir mes échanges suite à la capture jointe sur les LKML
Cordialement
nbanba
Bonjour,
Pour information, le problème n'intervient que si l'accès authentifier est activé (1 janv. 1970 01:00). Pas de problème de date si l'authentification est désactivée(Win 11 24H2, macOS Sequoia 15.5 RC, Ubuntu 24.04 LTS).
Il n'y aurait pas un problème côté timestamp avec "btime" d'utilisé au lieu de "ctime" ?
Bonjour
@itanium
Pourriez vous SVP faire un pcap dans les 2 cas et poster ici ?
(Dans mon cas sous Linux je ne capture pas la requête "SetInfo", (ou je suis passé à côté))
Merci
Cordialement
nbanba
Je n'ai malheuresement pas le temps de debug mais étrangement j'avais ceci après avoir activé l'authentification
Create Response (0x05) StructureSize: 0x0059 0000 0000 0101 100. = Fixed Part Length: 44 .... .... .... ...1 = Dynamic Part: True Oplock: No oplock (0x00) Response Flags: 0x00 .... ...0 = ReparsePoint: False Create Action: The file existed and was opened (1) Create: Apr 29, 2025 12:30:03.512954300 Paris, Madrid (heure d’été) Last Access: Apr 29, 2025 12:30:03.512954300 Paris, Madrid (heure d’été) Last Write: Jan 1, 1970 01:00:00.000000000 Paris, Madrid Last Change: Jan 1, 1970 01:00:00.000000000 Paris, MadridJe désactive l'authentification les dates sont ok. Je réactive… les dates sont correct sous Windows et macOS…
Il faudrait tester après un reboot de la box.
Bonjour
Malheureusement je n'ai pas de Windows en service pour tester…
J'ai un ISO W2022 ⇒ je vais voir si j'arrive à l'installer (sous KVM)
Pas sur que j'y arrive, la dernière fois que j'ai essayé j'ai bien installé le driver VirtIO pour le stockage mais je n'ai pas installé le serveur graphique de Windows et tout le monde s'est foutu de moi au bureau !
Cordialement
nbanba
Bonjour,
J'ai également le même problème même sous freebox OS 4.9.4
Sous Windows 10 ou windows 11 ça ne change rien.
Copie, d'un fichier depuis windows sur le disque dur interne de la freebox Ultra, dans les propriétés c'est indiqué "Modifié le : jeudi 1 janvier 1970, 01:00:00"
Bonjour,
Jusqu'à présent le problème est que les propriétés du fichier sont modifiées lors de la copie du disque de la freebox vers le disque du pc et non l'inverse.
Chez vous avec l'Ultra, c'est donc bien dans le sens inverse ?
Cordialement
Le problème vient d'apparaitre chez moi
Copie depuis le fileshare, teste sur plusieurs machines (Windows 10), la date de modification est remise a l'epoch 01/01/1970. Robocopy n'a pas le soucis.
C'est arrive après un redemarrage (et je suppose une mise a jour). Malheureusement comme on ne peut pas rollback les mises a jours facilement, ma solution de backup de fichier qui diff en se basant sur la taille et la date de modification ne fonctionne plus.
Correction, depuis le PC si :
- si je copie un fichier du disque dur interne du PC vers la Freebox les propriétés sont OK.
- si copie d'un fichier de la freebox vers le PC, date de modification au 01/01/1970
- si copie d'un fichier de la freebox vers un autre repertoire de la freebox, date de modification au 01/01/1970
Est-ce possible de préciser vos versions de Linux, macOS et de Windows impactées et dans quel sens ? (Note : @Math68 a été bien clair sauf pour les versions de Windows).
@itanium a dit ici : https://dev.freebox.fr/bugs/task/40205#comment189297
Pour information, le problème n'intervient que si l'accès authentifier est activé (1 janv. 1970 01:00). Pas de problème de date si l'authentification est désactivée(Win 11 24H2, macOS Sequoia 15.5 RC, Ubuntu 24.04 LTS).
@Math68 a dit ici : https://dev.freebox.fr/bugs/task/40205#comment189572
Correction, depuis le PC si :
- si je copie un fichier du disque dur interne du PC vers la Freebox les propriétés sont OK.
- si copie d'un fichier de la freebox vers le PC, date de modification au 01/01/1970
- si copie d'un fichier de la freebox vers un autre repertoire de la freebox, date de modification au 01/01/1970
Je suis sous Windows 11 avec les dernières Maj.
C'était pareil avec mon PC sous Windows 10.
Le problème est résolu si au niveau des paramètres de la Freebox on désactive la case "Activer SMB2/SMB3", tout en réactivant SMB1 client sous Windows.
Edition Windows 10 Home
Version 2009
Installed on 2024-12-09
OS Build 19045.5854
Windows 10 Version 22H2
Lors d'une copie depuis la freebox fileshare vers mon PC, la date de modification est mise a 01/01/1970
Lors d'une copie depuis mon PC vers la freebox fileshare, la date est correct.
Une commande:
robocopy \\Freebox_Server\FreeBoxSharedDri\TESTFOLDER D:\TESTFOLDER /mir
n'a pas de probleme de date de modification (elle correspond avec la source, dans les deux sens).
Je ne peux malheureusement pas test la solution en desactivant SMB2/SMB3 et en activant SMB1 sur la machine Windows.
macOS Catalina 10.15.7 et Sonoma 14.7.4.
Problème spécifique à SMB, aucun souci en AFP.
Un peu plus de détails :
Problème apparu le 17 mai suite au redémarrage impromptu de la Freebox et màj vers version 4.9.x. (je ne sais pas quelle était la version exacte à ce moment là, je ne me rendu compte du problème que plus tard en voulant trier les enregistrements de la Freebox sur leur date de création)
Aujourd'hui en 4.9.3.
Tout fichier créé sur la Freebox a sa date de création à l'epoch.
Un fichier créé avec l'apparition du bug récupère sa bonne date de création si copié depuis la Freebox vers macOS avec préservation des attributs (cp -p)
Là où c'est rigolo : montage du partage en SMB, descente dans un répertoire : les bonnes dates de création apparaissent un bref instant avant d'être remplacées par l'epoch (01/01/1970).
Mais avec Catalina, affichage de la colonne date de modification et zou, les bonnes dates de création ré-apparaissent.
Même manipulation avec Sonoma et seulement quelques fichiers récupèrent leur bonne date de création, la plupart restent en epoch.
Fsck la correction automatique :
Un fichier créé avant l'apparition du bug récupère sa bonne date de création si copié depuis la Freebox vers macOS avec préservation des attributs (cp -p).
@mmakassikis : Ce ticket est lié à :
- https://dev.freebox.fr/bugs/task/40170
- https://dev.freebox.fr/bugs/task/40205
- https://dev.freebox.fr/bugs/task/40298 (fermé)
@CerBerE, @mcorb ont commenté sur 40170.
@HPie, @nbanba, @freewhynot, @itanium, @Math68, @mcorb, @yetanotherlogin ont commenté ici (40205).
@maet, @SP94, @Padrys ont commenté sur 40298.
Je pense qu'il est nécessaire de créer un ticket sur afin que l'auteur de ksmbd/ksmbd-tools soit au courant du problème de date : Heure Unix / Heure POSIX / Unix time / Epoch time (Jan 1, 1970 01:00:00.000000000 CET) :
- https://github.com/cifsd-team/ksmbd-tools/issues
- https://github.com/namjaejeon/ksmbd-tools/issues
- https://github.com/cifsd-team/ksmbd/issues
- https://github.com/namjaejeon/ksmbd/issues
@CerBerE sur 40170 a indiqué :
- https://dev.freebox.fr/bugs/task/40170
Depuis MàJ freebox OS 4.9.1
Partage de fichiers SMB
Coté client macOS 15.3.2 (iMac Intel 2019)
Les fichiers apparaissent tous avec la date du 1 janvier 1970 !
- https://www.httprogress.fr/Capture_2025-03-27_20.37.29.png
Coté freebox se sont les bonnes dates
- https://www.httprogress.fr/Capture_2025-03-27_20.45.29.png