SAMU

0 octets reste 0 octet, s'il n'y a rien à sauvegarder ! Pour les 100 Ko tu as raison sur le principe, ils occupent 100 Mo (1Ko/secteur). Il ne s'agit ici que de montrer l'absurdité de la situation. Et ça n'explique aucunement la perte de 2,4 Go à chaque sauvegarde !

Il s'agit bien de ce qui est utilisé sur le disque, rapporté par le "Gestionnaire de stockage" et non de la "taille occupée par les fichiers". P.S Je le rajoute à mon message d'origine pour éviter toute confusion.

A.S. Je viens d'ouvrir également un sujet sur Time Backup "mangeant" 100 Go à chaque sauvegarde de 100 Go sur mon Syno cible sous DSM 5 beta: http://www.nas-forum.com/topic/39152-time-backup/#entry1319217488 Time Backup est une sauvegarde incrémentale. Mes sauvegardes portent sur 100 Go (100 000 fichiers dans 5 000 répertoires). Une sauvegarde des fichiers modifiés est programmée à chaque heure. Jusqu'à présent j'utilisais Robocopy. Avant de basculer définitivement sur TimeBackup je l'ai testé sans qu'aucun fichier source ne soit modifié. Le résultat est que 2,4 Go sont "mangés" à chaque sauvegarde. Il ne s'agit pas de la "taille occupée par les fichiers" mais bien de ce qui utilisé sur le disque, rapporté par le "Gestionnaire de stockage" ! Alors qu'avec Robocopy je suis capable de conserver les sauvegardes sur plusieurs années, cela devient impossible avec TimeBackup, En effet, sans même sauvegarder 1 seul octet, il n'est possible de conserver que 17 jours de sauvegarde sur 1To ! J'ai interrogé SYNOLOGY qui me dit que cela n'est pas possible, mais le fait est là, et je n'ai toujours pas de retour de leur intervention sur mon serveur (problème soumis depuis 15 jours). J'ai simulé la sauvegarde de 100 Ko depuis un répertoire comportant 100 000 fichiers de 1 octet répartis dans 10 000 sous répertoires. Pourtant, sans la moindre modification de fichier, TimeBackup "mange" à chaque sauvegarde 40 Mo, soit 400 fois ce que représentent les fichiers sources par eux-mêmes ! ...suite Mon appel à l'assistance de SYNOLOGY semble avoir porté ses fruits. Je rajoute donc ici la conclusion de leur intervention sur mon DS413 (reçue le 13 mars 2013) : "This is a known issue and will be a newer hotfix available coming in few weeks. Sorry for your inconvenience" :("Cette situation est identifiée et un nouveau correctif sera disponible dans quelques semaines. Désolé que cela vous crée problème.") Cependant, voir l'explication de SYNOLOGY ici:

Il y a très longtemps que j'utilise Robocopy (depuis XP, avant même qu'il ne soit intégré à Windows). Je l'ai utilisé avec différents NAS (NAS source et NAS cible). Maintenant il est utilisé avec un DS413. Personnellement je ne trouve aucun intérêt à recopier les ACL (le fait de recopier dans le répertoire approprié redonnant le bon ACL). J'ai pas mal développé autour de Robocopy (uniquement pour "Groupe de travail, pas pour "Domaine"). Si mon expérience peut t'aider. Je me ferais un plaisir... As-tu pu simuler une situation réduite au minimum avec une ligne de commande simplifiée de Robocopy qui recrée ton problème ?

Merci CoolRaoul pour tes précisions. J'avais bien essayé en rajoutant le nom de l'utilisateur, le groupe etc. dont le groupe "administrateurs", en fait nommé "administrators" (ceci me rappelle d'ailleurs un bug de traduction que j'ai déjà rencontré mais qui ne semble pas recouvrir la situation observée). J'ai suivi ta suggestion et "tracé" avec le journal de transfert. - aucune erreur n'est rapportée; - si je décoche "Permettre la modification de la liste de contrôle d'accès Windows", pour que Word enregistre, toutes les opérations sont reportées comme réalisées par l'utilisateur de session. Sur ton conseil, j'ai téléchargé "process monitor". Je regarderai dès que possible. De toute façon, ce qui me dérange le plus c'est que tout laisse à penser que la mise à jour vers DSM4.2-3202 est en cause. Comme j'ai déjà beaucoup de mal à obtenir une réponse concrète de Synology à un gros problème de pourrissage de disque par TimeBackup (2 Go de mangé chaque heure à chaque backup incrémental, sans fichier source modifié), j'attends pour leur soumettre ce nouveau problème que le premier ait avancé.

Ca ne change, hélas, rien ! Le dossier est accessible par défaut à "Tout le monde". J'ai essayé en rajoutant le nom de l'utilisateur, le groupe etc...le problème reste inchangé. De toute façon, c'est le système qui vérifie les droits. Mais cela ne se produit que pour OFFICE STARTER. Par exemple OFFICE 2010, NOTEPAD, WORDPAD etc... enregistrent sans problème !

Bonjour, Ce problème ne m'a été signalé que depuis la mise à jour du DS413 vers DSM4.2-3202. A partir de WORD et EXCEL STARTER 2010, il est impossible, pour les utilisateurs déclarés administrateurs sur le DS413, de sauver les fichiers dans un répertoire pour lequel a été coché: "Permettre la modification de la liste de contrôle d'accès Windows". On obtient le message "Accès refusé. Contactez votre administrateur". Ce problème est présent pour tous les PC (sous W7 et VISTA). Depuis un OFFICE 2010 NON-STARTER ce problème ne se manifeste pas. OFFICE STARTER utilise, lui, la virtualisation (disque Q:) : ce pourrait être une piste. Les seules solutions que j'ai trouvées, mais qui ne me satisfont vraiment pas, sont - soit de décocher sur le SYNO "Permettre la modification de la liste de contrôle d'accès Windows", - soit de déclasser l'utilisateur dont je retire les droits d'administrateur sur le SYNO. Avez-vous rencontré aussi ce problème ? Qui aurait une explication...et si possible...une solution ? SAMU P.S. Petits détails interressants: - un fichier de 0 octet; du nom demandé dans "Enregistre sous", est créé dans le répertoire avant le message de refus; - si le répertoire dispose d'une corbeille, un fichier temporaire (la sauvegarde du document) contenant le document s'y trouve (comme c'est aussi le cas quand tout est OK).