Backup dies is there is a file with spaces in the drupal dir.
| Project: | backup |
| Version: | 5.x-4.x-dev |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | dmuth |
| Status: | active |
Jump to:
tar output: tar: Drupal: Cannot stat: No such file or directory tar output: tar: 5: Cannot stat: No such file or directory tar output: tar: 20070205: Cannot stat: No such file or directory tar output: tar: 0200.sql: Cannot stat: No such file or directory tar output: tar: Error exit delayed from previous errors
I know that spaces are just bad mojo, but I've also been using MySQLAdmin, which created a file called Drupal 5 20070205 0200.sql seen here.
There's a couple of fixes possible - like quoting the included files, (and of course avoiding spaces) but I think the current
"list everything in root, then remove the backup-looking files, then put the latest database file back, then tell tar to do everything on this list"
method is a bit flaky. When it should be just "backup this dir"
Plus, the write-access needed to the root dir is a bad thing.
In my versions, I've automated my archives to go into the sites files/ directory, with the older backups landing in files/backups/archives and that folder being -excluded
I see you mention problems with tar -exclude - have you tried it on a directory?
#1
Okay, spaces in filenames definitely shouldn't break things. I'll look into that.
Yes, I tried excluding a directory in the past. And what it came down to was this: too many different versions of tar out there with too many different ways to exclude directories made it far more trouble than it was worth to try and get exclusions to work reliably. I should mention that I was developing backup on my OS/X box, which had a version of tar that behaved even differently from other versions I saw, so yeah...
-- Doug
#2
Files/URLs are not accessible if they contain reserved or non-ascii characters.
See url_generation.patch here http://drupal.org/node/43505#comment-316523