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 -> [email protected]

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 Answer 1

2

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.

5
  • What about my -x "..*" Won't it avoid going to parent of the root? I have been using this for years... Mar 20, 2019 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). Mar 20, 2019 at 17:14
  • Oh I missed when you said "before filtering excluded patterns"... that might explain all this... wow... Thanks Mar 20, 2019 at 17:19
  • That means my -x "..*" strategy looks into lot of unnecessary places... I would need to update this everywhere, LOL....... Mar 20, 2019 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. Mar 20, 2019 at 17:23

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .