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
Vous devez vous connecter pour publier un commentaire.
Je rencontre également le goudron messages "changé, comme nous l'avons lu". Pour moi, ce message s'est produite lorsque j'ai été prise de fichier tar de système de fichiers Linux dans bitbake environnement de construction. Cette erreur a été sporadique.
Pour moi ce n'était pas due à la création de fichier tar à partir du même répertoire. Je suis en supposant qu'il est en fait un fichier remplacé ou modifié pendant le goudron de la création du fichier.
Le message est un avertissement, et il continue à créer le fichier tar. On peut toujours supprimer ces message d'avertissement en option de réglage
--warning=no-file-changed
(http://www.gnu.org/software/tar/manual/html_section/warnings.html
)
Encore le code de sortie de retour par le goudron est "1" dans le message d'avertissement en cas:
http://www.gnu.org/software/tar/manual/html_section/Synopsis.html
Donc, si nous appelons le fichier tar de certaines fonctions dans les scripts, nous pouvons gérer le code de sortie à quelque chose comme ceci:
1
: "Si le goudron a été donné `--create', `--append' ou `--mise à jour de l'option, ce code de sortie signifie que certains fichiers ont été modifiés, tout en étant archivé et donc l'archive résultante ne contient pas la copie exacte de l'ensemble des fichiers." C'est comme décrocher la mâchoire, le mauvais comportement -- il va tuer un pipeline et il n'y a aucun moyen de l'arrêter. facepalmset +e
set -o pipefail; tar ... | gzip
. Mais je la renvoie; il n'est pas de tuer l'ensemble du pipeline, parce que la sortie est reportée jusqu'à la fin de l'exécution.Si vous voulez aider à déboguer un problème comme cela, vous devez fournir les faire à la règle ou au moins la commande tar vous avez appelé. Comment peut-on voir quel est le problème avec la commande si il n'y a pas de commande pour voir?
Cependant, 99% du temps une erreur comme ceci signifie que vous êtes en train de créer le fichier tar dans un répertoire que vous essayez de mettre dans le fichier tar. Ainsi, lorsque le goudron essaie de lire le répertoire, il trouve le fichier tar en tant que membre de l'annuaire, commence à la lire et l'écrire dans le fichier tar, et donc entre le moment où elle commence à lire le fichier tar et quand il a fini de lire le fichier tar, tar fichier a été modifié.
Ainsi, par exemple quelque chose comme:
Il n'y a aucun moyen de "stop", car il n'est pas mal. Il suffit de mettre votre fichier tar ailleurs quand vous le créer, ou trouver une autre façon (à l'aide de
--exclude
ou quoi que ce soit) d'omettre le fichier tar.@
dans vos règles et l'examen de la commande qui font de l'impression d'être sûr que c'est correct, et regarder les fichiers tar est en train de créer (sortie de l'option v) pour s'assurer il n'y a rien de mystérieux.Bien que son très tard, mais j'ai récemment eu le même problème.
Parce que dir
.
est en train de changerxyz.tar.gz
est créé après l'exécution de la commande. Il y a deux solutions:Solution 1:
tar
ne sera pas l'esprit si l'archive est créé dans le répertoire de l'intérieur.
. Il peut y avoir des raisons pourquoi on ne peut pas créer l'archive à l'extérieur de l'espace de travail. Travaillé autour d'elle par la création d'un répertoire temporaire pour mettre les archives en tant qu':Solution 2:
Celui que j'aime. créer le fichier d'archive avant l'exécution de goudron:
--exclude=archive.tar.gz
avant les autres optiosn-zvcf
et cela fonctionne bien.Ici est un one-liner pour ignorer le goudron de statut de sortie si elle est 1. Il n'est pas nécessaire de
set +e
comme dans sandeep du script. Si le goudron de statut de sortie est 0 ou 1, ce one-liner sera de retour avec la sortie d'état de 0. Sinon, il sera de retour avec la sortie d'état 1. Ceci est différent de la sandeep du script où l'origine de la sortie de statut de valeur est conservée si elle est différente de 1.tar -czf sample.tar.gz dir1 dir2 || [[ $? -eq 1 ]]
Pour améliorer Fabian du one-liner; disons que nous voulons ignorer seule porte de sortie d'état 1, mais pour préserver le statut de sortie si c'est autre chose:
Ce n'est tout de sandeep du script n', sur une seule ligne.
Simplement à l'aide d'un extérieur répertoire pour la sortie, a résolu le problème pour moi.