Restore Fails 'Could not create directory)

Hi Keith,

I think if you de-install and re-install with a fresh download from www.ads-software.com (though the version will be the same), the first error will be gone; that was there for a short time interval earlier today.

For the latter ones, I suspect that your setup has some kind of hard limit for the maximum length of a path. You could test that theory by downloading any plugin from www.ads-software.com, unzipping it, and then creating a very deep sub-directory structure (so that, e.g. the path name is approx 200 characters long), zipping it back up, and then trying to install the plugin. Do let us know the results!

Best wishes,
David

Hi David,

Thanks for your prompt response. I did what you said:

1) I downloaded a random plugin (Social Exchange)
2) I created a directory structure similar to the length of the path that Updraft appears to want to write to. Based on the error message in the logs the directory it’s trying to create is:

C:\Program Files\BitNami WAMP Stack\apps\wordpressfoxy\htdocs\wp-content\plugins\updraftplus\opencloud\rackspace\php-opencloud\lib\OpenCloud\CloudMonitoring\Exception

3) I extracted the Social Exchange plugin to

C:\Program Files\BitNami WAMP Stack\apps\wordpressfoxy\htdocs\wp-content\plugins\updraftplus\opencloud\rackspace\php-opencloud\lib\OpenCloud\CloudMonitoring\Exception\SocialExchange

which actually created 2 directories below that (…social-exchange-plugin\css

4) I then zipped it up from this new directory structure

5) I installed plugin from the newly created zip and it worked fine

This seems to indicate that it isn’t a limit on number of characters in my system (never, ever had an issue with this). My research shows that maximum path length is 260 on windows but this path is only 170+ so nowhere near it.

I also tried manually creating the above path (so updraft perhaps didn’t need to then create it) but this did’t work (ie I created it fine but still got same error on restore).

Any other ideas?

Regards
Keith

Hi Keith,

During the restore process, UD creates a temporary directory inside wp-content/upgrade whose name matches the name of the zip file being restored from. That zip file could be quite long – they are things like (to pick one of mine):

backup_2013-12-05-2255_Nondefault_directory_test_d21f04549161-plugins.zip

Hence, you could have something like:

C:\Program Files\BitNami WAMP Stack\apps\wordpressfoxy\htdocs\wp-content\upgrades/backup_2013-12-05-2255_Nondefault_directory_test_d21f04549161-plugins/plugins/updraftplus/opencloud/rackspace/php-opencloud/lib/OpenCloud/CloudMonitoring/Exception

That comes to 246 characters.

What are yours called? The site name in the middle can use up up to 32 characters – so I guess yours is a few characters longer, taking us over the 256. I thought that 256-character pathname limits perished with the passing of Windows 98! You live and learn!

So, my guess is it’s still that. I will look at what can be done. UD is re-using part of WordPress’s zip-file unpacking code here, which is why it’s choosing to use the long filename.

However, as a workaround, you can simply rename that middle section of the filename – don’t tweak the other parts, but tweak the descriptive text in the middle – does that work?

David

Hi David,

Once again thanks for the prompt reply.

You were right!!! It seems to pick up part of the file name from the Blog Title. Originally, my blog title was

Keith's WP Lucid Theme Test Blog

which created a backup file name of

backup_2013-12-12-1743_Keith039s_WP_Lucid_Theme_Test_871a9f7b27f2-others.zip

I renamed the blog to just “Test” creating a backup file of

backup_2013-12-14-1123_Test_97ded036cca6-others.zip

When I did this, the restore worked fine.

So we now know what is the cause, but not sure how to overcome it.

The first bit of the backup filename is the date/time, 2nd bit is my Blog name, I assume the 3rd bit is the UD backupid and the 4th bit is the entity type. Can’t see how I can effect anything but the blog name and I can’t keep calling them “Test”!!!

There are a few things that come to mind:
1) Do I actually need this long directory name? ie I’m not backing up to the cloud. However I suspect that UD is utilising some form of cloud based storage during the process and I suspect using the directory as a form of tracking?

2) What would overcome it is if you were able to define the backupset name via the control panel. You could then put a limit on the length of this (so directory name can’t be over x characters). It would also be a more user friendly way of identifying backup sets on the server and may even be a way of utilising the ‘backupset name’ to identify different types of backup

3) Would it be easier to change the code to just save it to a directory nearer the root or simply change the file/directory names to take up less characters?

Obviously you will know better than I what is easiest/best solution.

Anyway, as (in this particular case) it’s only a test environment I can work round it for the time being (on the assumption that it won’t be an issue in a live, Linux hosted environment)

Thanks very much for your help.

Let me know if you have any suggestions in the meanwhile or how you intend to resolve the issue.

Regards
Keith

I’ve just being doing some further testing:

I reduced the length of the Blog Title size gradually and at 5 characters long, UD actually deleted several plugins which I easily solved by re-downloading (plugin settings still remained from previous install).

Seems ok when Title is <5 chars
In summary, when Blog Title is
>5 characters – backs up but won’t restore
5 characters – kills plugins and have to re upload plugins
<4 – backs up and restores OK

Not a lot of room for movement on Blog Title though :).

A few other things:
1) Can’t find a log of the restore activity (ie like the one it prints to the screen). Does one exist and if so where is it located?
2) Prior to backup, on a one-time backup, what does ‘Don’t send this backup to cloud storage’ do if you are backing up via FTP? (Presumably not applicable to me)

Regards
Keith

Hi Keith,

For setting that part of the filename on the source side, you can use a filter, updraftplus_blog_name.

i.e. create a file wp-content/mu-plugins/blogname.php (create the mu-plugins directory if it does not already exist), with contents like so (to set it to ‘Test’):

<?php
add_filter(‘updraftplus_blog_name’, ‘my_updraftplus_blog_name’);
function my_updraftplus_blog_name($v) { return ‘Test’; }

During a restore, your plugins aren’t totally deleted. They are moved into wp-content/updraft/plugins-old or into wp-content/plugins-old (which one depends on the available file permissions). So, you can always retrieve them from there.

The problem’s not to do with the cloud. It’s to do with the directory name that WordPress decides to use when asked to unzip a file. I need to look around in the WordPress core code to see if there’s a way to over-ride it. I will get back to you!

David

Hi Keith,

If you update to the development version (or in fact, just de-install/re-install – I’ve also updated the current release, 1.8.2), then that should fix it. I’ve over-ridden WP’s choice of what temporary folder name to use when unzipping; now it’ll use only 8 characters, which should give you plenty of headroom!

Best wishes,
David

Hi David,

Thanks very much for your assistance. It is much appreciated.

However I’ve deleted and reinstalled the plugin buta am now getting a different error. I get this even when the blog name is only 4 characters long.

Plugins

Unpacking backup...
Moving old data out of the way...
Moving unpacked backup into place...
Error message: Could not move the files into place. Check your file permissions.
Restore failed...

There was also nothing in the plugins-old directory so my plugins have also disappeared (no problem – just restored them manually)

Any ideas?

Regard
Keith

Hi Keith,

Try de-installing, then installing the development version:
https://updraftplus.com/faqs/devversion

That will have the same result, but log more info – please post the log (which will be linked from the top of the restore page, or found in wp-content/updraft).

Also, after that, try adding this to wp-config.php and seeing if it makes a difference to the outcome:
define(‘FS_CHMOD_DIR’, 0777);

I made some changes to the file permissions handling yesterday; changes that in theory could not make anything worse, only better. It did that in all the tests I could think of… but, I may have missed something. If neither of the above work, then send me an email at contact at updraftplus dot com and I will email you back a version with some changes.

Best wishes,
David

P.S. There are *two* plugins-old directories, but only one will be used. You may have looked in the wrong one.

David

Hi David,

Get same error with development version. Log file below.

0000.075 () Opened log file at time: Sat, 14 Dec 2013 22:34:03 +0000
0000.076 () UpdraftPlus WordPress backup plugin (https://updraftplus.com): 1.8.2 WP: 3.8 PHP: 5.4.22 (Windows NT AFLAPTOP 6.1 build 7601 (Windows 7 Business Edition Service Pack 1) i586) MySQL: 5.5.32 Server: Apache safe_mode: 0 max_execution_time: 900 memory_limit: 256M (used: 11.7M | 12M) multisite: N mcrypt: Y ZipArchive::addFile: Y
0000.077 () Free space on disk containing Updraft's temporary directory: 152968.8 Mb
0000.077 () Restore job started. Entities to restore:
0000.148 () Entity: db
0000.148 () Unpacking backup...
0000.154 () Restoring the database (on a large site this can take a long time - if it times out (which can happen if your web hosting company has configured your hosting to limit resources) then you should use a different method, such as phpMyAdmin)...
0000.173 () Tried to raise max_allowed_packet from 16 Mb to 32 Mb, but failed (Access denied; you need (at least one of) the SUPER privilege(s) for this operation, b:0;)
0000.173 () Max packet size: 16 Mb
0000.174 () <strong>Backup of:</strong> https://localhost/wordpresstest
0000.175 () Content URL: https://localhost/wordpresstest/wp-content
0000.175 () Old table prefix: wp_
0000.175 () Site information: multisite=0
0000.178 () New table prefix: wp_
0000.232 () Restoring table (InnoDB): wp_options
0000.526 () Restoring table (InnoDB): wp_users
0000.680 () Restoring table (InnoDB): wp_usermeta
0000.830 () Restoring table (InnoDB): wp_commentmeta
0000.951 () Restoring table (InnoDB): wp_comments
0001.099 () Restoring table (InnoDB): wp_links
0001.286 () Restoring table (InnoDB): wp_postmeta
0001.635 () Restoring table (InnoDB): wp_posts
0002.290 () Restoring table (InnoDB): wp_term_relationships
0002.704 () Restoring table (InnoDB): wp_term_taxonomy
0002.903 () Restoring table (InnoDB): wp_terms
0003.081 () Finished: lines processed: 39 in 2.91 seconds
0003.083 () Cleaning up rubbish...
0003.094 () Entity: others
0003.094 () Unpacking backup...
0003.490 () Cleaning up rubbish...
0003.491 () Entity: plugins
0003.492 () Unpacking backup...
0013.536 () Moving old data: filesystem method / updraft_dir is potentially possible
0013.537 () Moving old data: can potentially use wp_filesystem method / -old
0013.537 () Moving old data out of the way...
0016.363 () Moving unpacked backup into place...
0017.902 () PHP event: code E_WARNING: copy(): The first argument to copy() function cannot be a directory (line 217, C:\Program Files\BitNami WAMP Stack\apps\wordpresstest\htdocs\wp-admin\includes\class-wp-filesystem-direct.php)
0017.908 () Error message: Could not move the files into place. Check your file permissions.
0017.908 () Error data: C:/Program Files/BitNami WAMP Stack/apps/wordpresstest/htdocs/wp-content/upgrade/f8afeeb4/plugins/jetpack -> C:/Program Files/BitNami WAMP Stack/apps/wordpresstest/htdocs/wp-content/plugins/jetpack
0017.908 () Restore failed...
0017.908 () Error message: Could not move the files into place. Check your file permissions.
0017.908 () Error data: C:/Program Files/BitNami WAMP Stack/apps/wordpresstest/htdocs/wp-content/upgrade/f8afeeb4/plugins/jetpack -> C:/Program Files/BitNami WAMP Stack/apps/wordpresstest/htdocs/wp-content/plugins/jetpack
0017.908 () Restore failed

Will try adding line to wp-config.php and get back to you.

Regards
Keith

Hi David,

Have added line to wp-config but still get same result as above. Hopefully the PHP error in line 0017.902 will tell you where the issue is.

Can happily restore manually so I know it’s not a major issue.

Thanks for your help though. It’s much appreciated.

Regards
Keith

Hi Keith,

That line means that it’s a file permissions problem. On the site involved, is it now possible to install a plugin through the normal WordPress installer mechanism?

David

One last thing before I go (back on Monday!)…

I’ve just tweaked the development version – it’ll show as 1.8.3 – if you re-install, and confirm first that your permissions are working enough to install a normal plugin (actually, installing the dev version will prove that!), and then try again… does it then work?

David

Hi David,

Apologies for the long gap in response.

Just wanted to let you know that this is now working fine.

Many thanks for all your help. It is much appreciated.

Regards
Keith