0

I have some weird warnings when zipping a directory's content. I use a command line I use for a ton of websites backup since years and never had such issue, and I try to figure out why I have the warnings (even though the zip files seem created correctly) and I fail to figure it out in a reasonable time (I have put what I found, keep reading).

I go in the directory I want to backup to a zip file:

cd /home/mickoz/michael.muryn.name

Here is the command I run (I tailored it to debug only and reproduce problem):

zip -r -qv test.zip * .* -x "..*" -x test.log -x test.zip > test.log

For some reason it logs these warnings right at the beginning:

zip warning: name not matched: ../logs/michael.muryn.name/http.2810216.bak/html/daily.html
zip warning: name not matched: ../logs/michael.muryn.name/http.2810216.bak/html/index.html
zip warning: name not matched: ../logs/michael.muryn.name/http.2810216.bak/html/longterm.html
zip warning: name not matched: ../logs/michael.muryn.name/http.2810216.bak/html/monthly.html
zip warning: name not matched: ../logs/michael.muryn.name/http.2810216.bak/html/resources
zip warning: name not matched: ../logs/mickoz.dreamhosters.com/http.2150913.bak/html/index.html
zip warning: name not matched: ../logs/mickoz.dreamhosters.com/http.2150913.bak/html/monthly.html
zip warning: name not matched: ../logs/mickoz.dreamhosters.com/http.2150913.bak/html/resources
zip warning: name not matched: ../logs/muryn.name/http.2810083.bak/html/index.html
zip warning: name not matched: ../logs/muryn.name/http.2810083.bak/html/monthly.html
zip warning: name not matched: ../logs/muryn.name/http.2810083.bak/html/resources
zip warning: name not matched: ../muryn.name/.#svn-commit.tmp

Now, there is NO symlinks in the directory I zip content of (I did execute a command to find if there was even deepdown and there is none).

Heck, just to be sure, I just even tried to create a new directory /home/mickoz/michael.muryn.name2, created two text files in it only. Run the same zip command I put above in that new directory... and the exact same warnings appear! Seem like it tries to search outside of the directory, but I fail to see why as I exclude "..*" in my zip command and that should do the job.

I even tried to do it in a directory named /home/mickoz/testzipbackup in case the dots in the directory name was causing problem and the same result.

Any idea what may be causing this? How can I debug this?


Additional infos:

There was a symbolic link located there

/home/mickoz/muryn.name/.#svn-commit.tmp -> mickoz@here.22973

Take note that the symlink was pointing to something non-existing. This seems important as I debug more and more.

I deleted it and re-executed my test zip command, and this line disappeared from the log:

zip warning: name not matched: ../muryn.name/.#svn-commit.tmp

So it definitely try to search outside the directory for some reason and I fail to see why it does it with what looks like symbolic link only, while excluding files correctly it seems.


From there I dug deeper and did a search for all symbolic links on my user account by using this command in the root of the home directory:

find . -type l -ls

Here is a specific and interesting sample of the result:

14575211295    0 lrwxrwxrwx   1 root     root           49 Aug  6  2011 ./logs/muryn.name/http.2810083 -> /home/_domain_logs/mickoz/muryn.name/http.2810083
14145610800    0 lrwxrwxrwx   1 root     root           21 Aug  6  2011 ./logs/muryn.name/http.2810083.bak/access.log.0 -> access.log.2011-08-05
14145612338    0 lrwxrwxrwx   1 root     root           20 Aug  6  2011 ./logs/muryn.name/http.2810083.bak/error.log.0 -> error.log.2011-08-05
15649147256    0 lrwxrwxrwx   1 root     root           67 Aug  5  2011 ./logs/muryn.name/http.2810083.bak/html/daily.html -> /home/mickoz/logs/muryn.name/http.2810083/html/inactive_report.html
15649147257    0 lrwxrwxrwx   1 root     root           73 Aug  5  2011 ./logs/muryn.name/http.2810083.bak/html/index.html -> /home/mickoz/logs/muryn.name/http.2810083/html/monthly/2011-08/index.html
15649147258    0 lrwxrwxrwx   1 root     root           66 Aug  5  2011 ./logs/muryn.name/http.2810083.bak/html/longterm.html -> /home/mickoz/logs/muryn.name/http.2810083/html/longterm/index.html
15649147259    0 lrwxrwxrwx   1 root     root           73 Aug  5  2011 ./logs/muryn.name/http.2810083.bak/html/monthly.html -> /home/mickoz/logs/muryn.name/http.2810083/html/monthly/2011-08/index.html
15649147260    0 lrwxrwxrwx   1 root     root           27 Oct 19  2009 ./logs/muryn.name/http.2810083.bak/html/resources -> /home/mickoz/logs/resources
14557793344    0 lrwxrwxrwx   1 root     root           49 Mar 19 15:12 ./logs/muryn.name/http -> /home/_domain_logs/mickoz/muryn.name/http.2810083

I analyzed this and found out that only symlinks that are pointing to non-existing target appears in my zip command warnings.

Now, only have to understand why the zip command looks for those symlinks outside of the working directory and only acts/emits a warning on the symlinks pointing to non-existing target.

1

There are two things going on here.

The first is that

zip -r -qv test.zip * .* -x "..*" -x test.log -x test.zip

is expanded by the shell to list everything matching * and .*, which includes .. in your case.

The second is that zip checks all the file names it’s given, when it’s asked to recurse, before filtering excluded patterns; so it sees ../logs/michael.muryn.name/http.2810216.bak/html/daily.html etc. and calls stat on them, which produces an error, and zip outputs “name not matched” as a result.

The usual way to avoid this is to specify .[^.]* instead of .*, or since you’re also matching *, run

zip -r -qv test.zip . -x test.log -x test.zip

instead.

  • What about my -x "..*" Won't it avoid going to parent of the root? I have been using this for years... – Michael Muryn Mar 20 at 17:11
  • Your -x option avoids storing the files from .. etc. in the archive, but it doesn’t avoid zip checking them: that’s what I meant when I wrote “The second is that zip checks all the file names it’s given, when it’s asked to recurse, before filtering excluded patterns” (excluded patterns being the patterns given with -x). – Stephen Kitt Mar 20 at 17:14
  • Oh I missed when you said "before filtering excluded patterns"... that might explain all this... wow... Thanks – Michael Muryn Mar 20 at 17:19
  • That means my -x "..*" strategy looks into lot of unnecessary places... I would need to update this everywhere, LOL....... – Michael Muryn Mar 20 at 17:20
  • The one with only the . seems to work... I endedup long long time ago tailoring that script to put .* because for some reason it was not including hidden files (starting with .) if my memory is right... oh well might have missed something back them... just using . seem pretty simple and clean. – Michael Muryn Mar 20 at 17:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.