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... Commented 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). Commented Mar 20, 2019 at 17:14
  • Oh I missed when you said "before filtering excluded patterns"... that might explain all this... wow... Thanks Commented 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....... Commented 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. Commented Mar 20, 2019 at 17:23

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.