goudron: fichier modifié comme nous l'avons lu

Je suis en utilisant make et tar de sauvegarde. Lors de l'exécution de makefile, commande tar montre file changed as we read it. Dans ce cas,

  • le package tar est ok lorsque l'avertissement arrive
  • mais cela s'arrête la commande tar pour la sauvegarde suivantes
  • le fichier indiquant l'avertissement en fait ne change pas -- il est vraiment étrange que l'avertissement arrive
  • les fichiers montrant l'avertissement viennent au hasard, je veux dire, à chaque fois que je lance mon makefile, les fichiers montrant l'avertissement sont différents
  • --ignore-failed-read ne l'aide pas. Je suis à l'aide de goudron de 1,23 MinGW
  • Je viens de changer mon ordinateur pour WIN7 64 bits. Le script fonctionne bien à l'ancienne WIN7 32 bits. Mais le goudron version n'est pas aussi nouveau que le 1,23.

Comment puis-je arrêter le goudron du avertissement pour arrêter ma sauvegarde la suite de l'avertissement?


Edit-2: il est peut-être la raison pour

Comme je l'ai dit ci-dessus, le shell bash script a bien fonctionné dans mon ancien ordinateur. En comparant avec l'ancien ordinateur, les msys version est différente. Ainsi est la version de la commande tar. Dans l'ancien ordinateur, le goudron est 1.13.19 et il est de 1,23 dans le nouvel ordinateur. J'ai copié le vieux goudron de commande sans copier ses dépendance msys-1.0.dll sur le nouvel ordinateur et l'a renommé tar_old. Et j'ai aussi mis à jour la commande tar dans le shell script et exécutez le script. Alors tout est ok. Et donc, il semble que le problème est la commande tar. Je suis sûre que ce n'est pas de n'importe quel fichier a changé quand tarage. Est-ce un bug pour la commande tar dans la nouvelle version? Je ne sais pas.


Edit-1: ajouter plus de détails

La sauvegarde est invoquée par un shell bash script. Il scanne le répertoire cible et s'appuie makefile invoque ensuite le faire pour utiliser la commande tar de sauvegarde. Suivi est typique d'un makefile construit par le shell bash script.

#--------------------------------------------
# backup VC
#--------------------------------------------
# the program for packing
PACK_TOOL=tar

# the option for packing tool
PACK_OPTION=cjvf

# M$: C driver
WIN_C_DIR=c:

# M$: D driver
WIN_D_DIR=d:

# M$: where the software is
WIN_PRG_DIR=wuyu/tools
# WIN_PRG_DIR=

# where to save the backup files
BAKDIR=/home/Wu.Y/MS_bak_MSYS

VC_FRAMEWORK=/home/Wu.Y/MS_bak_MSYS/tools/VC/VC_framework.tar.bz2
VC_2010=/home/Wu.Y/MS_bak_MSYS/tools/VC/VC_2010.tar.bz2

.PHONY: all

all: $(VC_FRAMEWORK) $(VC_2010)

$(VC_FRAMEWORK): $(WIN_C_DIR)/$(WIN_PRG_DIR)/VC/Framework/*
    @$(PACK_TOOL) $(PACK_OPTION) "$@" --ignore-failed-read /c/$(WIN_PRG_DIR)/VC/Framework
$(VC_2010): $(WIN_C_DIR)/$(WIN_PRG_DIR)/VC/VS2010/*
    @$(PACK_TOOL) $(PACK_OPTION) "$@" --ignore-failed-read /c/$(WIN_PRG_DIR)/VC/VS2010

Comme vous pouvez le voir, le goudron package est stocké dans ~/MS_bak_MSYS/outils/VC/VC_2010.le goudron.bz2. Je lance le script dans ~/qqaa. ~/MS_bak_MSYS est exclu de la commande tar. Donc, le fichier tar je suis de la création n'est pas à l'intérieur d'un répertoire que je suis en train de mettre en fichier tar. C'est pourquoi je me sentais étrange que l'avertissement est venu.

  • On dirait que vous êtes à l'aide de l'installation de windows, donc pas pertinent pour vous. Pourtant, nous avons ce genre de problème lorsque le système de fichiers sous-jacent est glusterfs. Il semble qu'il y est un bug lors de la lstat et fstat retour des valeurs différentes: bugzilla.redhat.com/show_bug.cgi?id=1058526
InformationsquelleAutor warem | 2013-12-02