Commit 0214a21d authored by Dmitriy Zaporozhets's avatar Dmitriy Zaporozhets

Merge branch 'restore_uploads_fix' into 'master'

Avoid "cannot copy directory ... to itself" error on restore (on Docker?)

rake gitlab:backup:restore fails for me in my Docker-hosted Gitlab-CE instance; during the restore, any existing "uploads" directory is backed up by [this code](https://gitlab.com/gitlab-org/gitlab-ce/blob/833bc30/lib/backup/uploads.rb#L23) --

```ruby
    def backup_existing_uploads_dir
      timestamped_uploads_path = File.join(app_uploads_dir, '..', "uploads.#{Time.now.to_i}")
      if File.exists?(app_uploads_dir)
        FileUtils.mv(app_uploads_dir, timestamped_uploads_path)
      end
    end
```

When this executes for me, the ```FileUtils.mv``` parameters are "/home/git/gitlab/public/uploads" and "/home/git/gitlab/public/uploads/../uploads.1407019546"; an exception is raised, producing this double stacktrace:

```
ArgumentError: cannot copy directory /home/git/gitlab/public/uploads to itself /home/git/gitlab/public/uploads/../uploads.1407019546
/home/git/gitlab/lib/backup/uploads.rb:26:in `backup_existing_uploads_dir'
/home/git/gitlab/lib/backup/uploads.rb:18:in `restore'
/home/git/gitlab/lib/tasks/gitlab/backup.rake:73:in `block (4 levels) in <top (required)>'
/home/git/gitlab/lib/tasks/gitlab/backup.rake:30:in `block (3 levels) in <top (required)>'
Errno::EXDEV: Invalid cross-device link @ sys_fail2 - (/home/git/gitlab/public/uploads, /home/git/gitlab/public/uploads/../uploads.1407019546)
/home/git/gitlab/lib/backup/uploads.rb:26:in `backup_existing_uploads_dir'
/home/git/gitlab/lib/backup/uploads.rb:18:in `restore'
/home/git/gitlab/lib/tasks/gitlab/backup.rake:73:in `block (4 levels) in <top (required)>'
/home/git/gitlab/lib/tasks/gitlab/backup.rake:30:in `block (3 levels) in <top (required)>'
Tasks: TOP => gitlab:backup:uploads:restore
(See full trace by running task with --trace)
```

I'm guessing from the first message that ```mv``` walks the destination path to ensure that we're not moving the source into itself -- it doesn't get as far as interpreting the '..', but throws when it sees that the destination appears to start with the source path.

The second stacktrace I have no clue about - maybe it's AUFS- or Docker-related?

I attempted to reproduce this separately with the omnibus distribution in a fresh Ubuntu 14.04 install without Docker involved, and was unable to - backup and restore worked fine. I then tested my theory by FileUtils.expand_path-ing the destination in my own Docker setup code, and that made the problem go away, so that's what this merge request does.

(I'm using backups created and restored on gitlab-ce 7-1-stable, at facfec4b; this is on Ubuntu 14.04 with Docker 1.1.1)

I know I'd look askance at a PR without tests for an unreproducable problem, but even if this is rejected, I'm submitting it anyway because maybe someone else will Google it and find it useful. I'm happy to do more work to improve this if you have suggestions.

See merge request !165
parents 29b6d465 fc9832b1
......@@ -23,7 +23,7 @@ module Backup
def backup_existing_uploads_dir
timestamped_uploads_path = File.join(app_uploads_dir, '..', "uploads.#{Time.now.to_i}")
if File.exists?(app_uploads_dir)
FileUtils.mv(app_uploads_dir, timestamped_uploads_path)
FileUtils.mv(app_uploads_dir, File.expand_path(timestamped_uploads_path))
end
end
end
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment