CoolRaoul

Oui, si on lui ajoute l'option "-r" (récursif). "rmdir" n'efface que les répertoires *vides*.

Bon, si il s'agit de montrer sa science, alors allons-y ... (pas taper hein, j'ai juste du temps à perdre ce soir!) "find ... -exec" n'est pas toujours très optimal si les fichiers trouvés sont nombreux. Je proposerai plutôt: find . -deph -name "FILE-TO-FIND" -print0 | xargs -0 rm -rf "-depth" pour éviter des erreurs dans le cas de répertoires imbriqués qui matchent tous deux la condition (en fait ça marche quand même sans c'est plus propre ainsi) le "-print0" pour find et le "-0" de xargs c'est au cas ou certains fichiers ont des espaces dans leurs noms.

Suffit de cliquer sur la loupe

Utiliser la fonction de recherche avancée de filestation avec comme emplacement tous les sous dossiers: de "photo" et type de fichier "tous les dossiers" ensuite sélectionner tous les items de la liste (clic sur le premier et shift-clic sur le dernier) puis "action->supprimer"

Je me suis lancé aussi et pas de problème non plus. Si tu n'est pas admin sur ton PC de boulot, y installer cloudstation risque déjà d'être sportif..

Exactement (au performances prés quand même).

Dès que le tunnel VPN est établi entre l'appareil Androïd et le NAS, on peut aussi accéder à ce dernier en utilisant son IP interne (habituellement en 198.168.N.P). De plus les acces utilisant cette IP ne sont pas filtrés le firewall du NAS et les ports n'auront pas besoin d'être redirigés dans la box. Ainsi, on peut se contenter d'ouvrir uniquement le (les) port(s) du protocole VPN dans le routeur et malgrès tout accéder avec son smartphone à tous les services du NAS (y compris SMB)

en effet **EDIT** petite astuce en prime, tel quel le script va *toujours* écrire dans le log. Si tu veux que la sortie continue à aller à l'écran lorsque tu l'exécute "à la main" remplace: exec >> /tmp/ftp_mirror.log 2>&1 par [ -t 0 ] || exec >> /tmp/ftp_mirror.log 2>&1 Le test préalable ("-t 0") à pour effet que la redirection ("exec >>") soit effectuée *uniquement* lorsque l'entrée standard n'est pas un terminal (ce qui est justement le cas en cron mais pas en ligne de commande).

en mettant la ligne "exec" que j'ai donnée dans le script (en début)

Avec la double redirection ("> bidule" suivi de "2>&1") le fichier log contiendra l'intégralité des messages émis par ton script si c'est bien de ça qu'il s'agit.

Suffira d'ajouter la ligne "export ..." *dans* le script qui invoque mkvmerge

Sous unix il y a toujours *deux* sorties pour chaque process: la sortie standard (descripteur 1) et la sortie d'erreur (descripteur 2) la simple redirection (">" ou "1>") ne redirige que la première.

Tant qu'a faire, ajoute aussi la sortie d'erreur a ton log, ca sera mieux: remplacer 1>> log.txt par >>log.txt 2>&1 **edit** Autre chose, faudrait spécifier le chemin *complet* du fichier log, et le mieux est de faire ça *dans* le script en y ajoutant la ligne: exec >> /tmp/ftp_mirror.log 2>&1

Ca dépend ou se trouve la commande "lftp" sur ton NAS (ce n'est pas une commande standard DSM) Si c'est un package optware il y a de forte chances que ceci fonctionne: PATH=/opt/bin:/bin:/usr/bin

Il manque la ligne "PATH=" **edit** En cron, le shell n'exécute pas les profiles, se retrouve avec le PATH par défaut, et il ne peut pas deviner ou se trouve le binaire "lftp"

Tu as oublié de déclarer le PATH dans ton script

En ce qui concerne le reverse proxy, le témoignage d'un collègue ayant appliqué l'update indique n'avoir rien constaté d'anormal de son coté. Je pense que je vais bientôt me lancer aussi alors.

Certains packages ipkg (non encore installés) mettent certains de leur binaires dans "/opt/sbin" tu peux l'ajouter au PATH (ça ne mange pas de pain) mais inutile de créér le dossier, il le sera lorsque necessaire

Est-ce que ça fait pareil après avoir tapé: export LANG=C (inspiré de http://forum.synology.com/enu/viewtopic.php?f=40&t=36845&start=15)

Pour exécuter le bootstrap faut être loggé "root", pas "admin" (même mot de passe)

Dans le script, ajouter la ligne: exec > /tmp/mount_local.log 2>&1juste apres la ligne "#!". Redémarrer et aller voir dans le contenu du .log généré ce qui a coincé. Il est important que le nom du script se termine par ".sh" aussi (en tout cas c'est ce qui est indiqué par le README situé dans mon "/usr/local/etc/rc.d" (doit dater d'une ancienne version de DSM sans doute)

Pas exactement; il est juste mentionné l'erreur: Configuring optware-bootstrap.ipk...mount: mounting /volume1/@optware on /opt failed: No such file or directory je pense qu'un simple "mkdir /opt" préalable devrait résoudre le probleme

Ca ne serait pas "/volume1/startup" plutôt? J'utilise une autre approche désormais pour les scripts de démarrage (et d’arrêt d'ailleurs), dans "/usr/local/etc/rc.d". CF ici:

Question pertinente. J'avais testé haproxy il y a pas mal de temps et il répondait aussi à mon besoin, mais un jour il est parti en vrille (fuite mémoire probablement) et m'a planté mon NAS: plus aucun accès à distance et je n'étais pas chez moi pour réparer bien entendu. J'imagine que le produit s'est fiabilisé depuis mais cet incident m'a un peu fait perdre confiance (un peu ennuyeux dans le cas d'un outil utilisé dans le cader d'acces distant qui doit être d'une robustesse à toute épreuve). Inversement, le reverse proxy qui n'utilise que des composants natifs de DSM ne m'a jamais fait défaut. Lors d'une mise a jour DSM, pour retrouver ma conf reverse proxy je n'ai qu'une ligne à ajouter dans http-user.conf, c'est pas bien compliqué.

Juste.. Pour l'instant j'ai trouvé un unique retour (négatif). Un seul positif suffirait à me rassurer. Pas possible que *tous* les utilisateurs de reverse proxy choisissent de temporiser quand même!