cricx

OK ! Je n'ai pas d'explication (

regarde dans /var/log/messages

création de fichiers avec espaces : DiskStation > for f in 1 2 3 4 5 c; do touch "fichier $f fin"; done DiskStation > ll total 8 drwxr-xr-x 2 root root 4096 Jun 19 15:13 . drwxr-xr-x 7 root root 4096 Jun 17 22:32 .. -rw-r--r-- 1 root root 0 Jun 19 15:13 fichier 1 fin -rw-r--r-- 1 root root 0 Jun 19 15:13 fichier 2 fin -rw-r--r-- 1 root root 0 Jun 19 15:13 fichier 3 fin -rw-r--r-- 1 root root 0 Jun 19 15:13 fichier 4 fin -rw-r--r-- 1 root root 0 Jun 19 15:13 fichier 5 fin -rw-r--r-- 1 root root 0 Jun 19 15:13 fichier c fin recherche et effacement de ces fichiers : DiskStation > find . -type f -name "fichier*" -exec rm "{}" \; DiskStation > ll total 8 drwxr-xr-x 2 root root 4096 Jun 19 15:14 . drwxr-xr-x 7 root root 4096 Jun 17 22:32 .. en script : #!/bin/ash for f in 1 2 3 4 5 c; do touch "fichier $f fin"; done ls -l find . -type f -name "fichier*" -exec rm "{}" \; ls -l DiskStation > ./script total 4 -rw-r--r-- 1 root root 0 Jun 19 15:18 fichier 1 fin -rw-r--r-- 1 root root 0 Jun 19 15:18 fichier 2 fin -rw-r--r-- 1 root root 0 Jun 19 15:18 fichier 3 fin -rw-r--r-- 1 root root 0 Jun 19 15:18 fichier 4 fin -rw-r--r-- 1 root root 0 Jun 19 15:18 fichier 5 fin -rw-r--r-- 1 root root 0 Jun 19 15:18 fichier c fin -rwxr-xr-x 1 root root 135 Jun 19 15:16 script total 4 -rwxr-xr-x 1 root root 135 Jun 19 15:16 script Donc ça fonctionne très bien. Dans ton script, le rm $line ne peut pas fonctionner, il faut rm "$line" (testé aussi avec des noms de répertoires avec epaces : ça marche)

find $MUSICDIR -type f -name "Thumbs.db" -exec rm "{}" \; simple côte en trop à la fin

Pas assez précis ta question, tu ne dis pas si tous tes périphériques sont sur ton lan! Si c'est le cas, il suffit de les référencer avec leur ip ou leur nom interne (soit dns local, soit fichier host sur le syno, pas besoin de reverse proxy

Pour l'instant aucun modèle n'est équipé et iln'y a pas d'annonce de la part de synology à ce sujet. Mais l'usb3 n'est vraiment pas une priorité sur un nas, ce qui laisse penser que le support (matériel comme logiciel) de l'usb3 n'est pas pour demain. Quant à l'esata, on n'est pas dans le même type d'interface. L'esata est en fait une interface sata, qui ne risque pas encore d'être remplacée par de l'usb (vitesse, ressources matérielles...). Comme son nom l'indique, l'usb est universelle (et pas dédiée à l'accès disque comme sata, qui est ata sur un lien série) et même en version 3 n'atteint pas les débits de sata2 (3 gb/s)

Je crois que le vrai problème est bien lié à l'incompréhension de ce qu'est l'iscsi. Il ne s'agit pas d'un protocole de partage (pas plus de fichier que de disque), mais de transport de données et de commandes à un bas niveau, comparable à atapi pour les interfaces ide. La manip faite (accéder à une même cible par deux "clients") revient à démonter un disque dur d'une machine pour le mettre sur une autre, en espérant que le bios comme le système d'exploitation, le système de fichiers iront le lire (et l'écrire) de la même manière que la première (sachant que l'accès est effectué à un bas niveau (blocs disque) dont très dépendant de nombreux paramètres, et sans prise en compte d'accès concurrents. Les informaticiens qui ont étudié depuis des années le problème d'accès et de partage des données ont bien compris que cela passait nécessairement par une couche applicative supplémentaire (samba, nfs, afs ou autres systèmes de fichier réseau). L'iscsi n'est absolument pas fait pour cela. Il faut voir un accès iscsi comme un disque branché physiquement à une machine. Pour la petite histoire, la gestion calamiteuse du réseau par microsoft (souvenez-vous qu'il a inventé netbeui !) fait que certaines applications fonctionnent différemment sur un "mappage" réseau. Ce n'est pas le cas sur les systèmes unix/linux pour lesquelles un module (un driver) gère l'accès : cifs, nfs et les multiples modules fuse comme gmailfs [un compte gmail apparait comme un disque local], ou un simple montage dans l'arborescence permet l'accès natif au système de fichiers distant comme s'il était local. Mais voilà, utiliser un protocole de manière inadaptée avec un système obsolète... Un petit détail : la corruption a été probablement été provoquée par le poste client et pas par le nas. Il faudrait cependant rechercher un peu si ce n'est pas une corruption côté nas a provoqué cette perte de données (ce qui peut arriver même sans iscsi)

le message d'erreur que tu as laisserait penser que l'audio est envoy