django collectstatic avec django-storages recopier tous les fichiers

Question

J'utilise django.contrib.staticfiles avec django-stockages pour déployer mes fichiers statiques sur Amazon S3. La version django que j'utilise est 1.10.4 et la version django-storages est 1.5.2. Maintenant, quand je lance collectstatic, il recopie tous les fichiers du système local vers S3 même s'il n'y a pas de changement dans les fichiers localement. En regardant le code de commande de gestion collectstatic Je peux voir:

Dans la méthode delete_file:

  # The full path of the target file 
      if self.local: 
       full_path = self.storage.path(prefixed_path) 
      else: 
       full_path = None 
      # Skip the file if the source file is younger 
      # Avoid sub-second precision (see #14665, #19540) 
      if (target_last_modified.replace(microsecond=0) >= source_last_modified.replace(microsecond=0) and 
        full_path and not (self.symlink^os.path.islink(full_path))): 
       if prefixed_path not in self.unmodified_files: 
        self.unmodified_files.append(prefixed_path) 
       self.log("Skipping '%s' (not modified)" % path) 
       return False 

Le débogage j'ai vu que même si le target_last_modified> = source_last_modified mais chemin_complet est Aucun qui est la raison pour laquelle la vérification échoue et finit par supprimer le fichier sur la télécommande. Je ne suis pas sûr de ce que je fais mal ou si j'ai manqué un réglage à cause de quoi il est en train de télécharger à nouveau les fichiers. Fait intéressant si je supprime la vérification supplémentaire dans le code ci-dessus et juste vérifier comme:

if (target_last_modified.replace(microsecond=0) >= source_last_modified.replace(microsecond=0)): 

cela fonctionne très bien.

J'ai vu des questions similaires sur le SO, mais elles sont principalement dues à des fuseaux horaires différents de S3 par rapport au système local. Dans mon cas, mon fuseau horaire local et la zone du compartiment S3 sont identiques. En tout cas, le hack ci-dessus montre que le problème n'est pas dû à la différence de fuseau horaire.

Answer 1

Notre solution était d'utiliser Collectfast:

https://github.com/jazzband/collectfast

Il met en cache et compare sommes MD5 des fichiers avant de les télécharger. Nous aimerions connaître la cause profonde du problème, mais cela a résolu la lenteur.