Freebox Server (Ultra V9/ Pop V8/ Delta V7 / Revolution V6 / Mini 4K)

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

$ cp /mnt/FBX24T/toto ./toto
$  stat ./toto
  Fichier : ./toto
   Taille : 5         	Blocs : 8          Blocs d'E/S : 4096   fichier
Périphérique : 0/48	Inœud : 11605309    Liens : 1
Accès : (0644/-rw-r--r--)  UID : ( 1000/     nba)   GID : ( 1000/     nba)
 Accès : 2025-04-06 18:44:18.321177316 +0200
Modif. : 2025-04-06 18:44:18.329177342 +0200
Changt : 2025-04-06 18:44:18.329177342 +0200
  Créé : 2025-04-06 18:44:18.321177316 +0200

copie en préservant les arguments comme le timestamp:

$ cp -a /mnt/FBX24T/toto ./toto
cp : voulez-vous écraser './toto' ? y
$ stat ./toto
  Fichier : ./toto
   Taille : 5         	Blocs : 8          Blocs d'E/S : 4096   fichier
Périphérique : 0/48	Inœud : 11605309    Liens : 1
Accès : (0666/-rw-rw-rw-)  UID : ( 1000/     nba)   GID : ( 1000/     nba)
 Accès : 2025-03-20 09:20:03.606017400 +0100
Modif. : 2025-03-20 09:20:03.606017400 +0100
Changt : 2025-04-06 18:44:58.817308727 +0200
  Créé : 2025-04-06 18:44:18.321177316 +0200

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.

$ cp -a /mnt/FBX24T/tata ./
$ stat /mnt/FBX24T/tata
  Fichier : /mnt/FBX24T/tata
   Taille : 30        	Blocs : 8          Blocs d'E/S : 16777216 fichier
Périphérique : 0/131	Inœud : 23          Liens : 1
Accès : (0666/-rw-rw-rw-)  UID : (    0/    root)   GID : (    0/    root)
 Accès : 2025-04-07 15:51:04.598676000 +0200
Modif. : 2025-04-07 15:51:04.598676000 +0200
Changt : 2025-04-07 15:51:04.598676000 +0200
  Créé : 2025-04-07 15:50:27.938676000 +0200

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 :

1. c'est toujours d'actualité en 4.9.2
2. ça ressemble fortement au bug https://dev.freebox.fr/bugs/task/40170