Improve error message regarding mismatched tmp directories when sql-syncing between systems with different fs layout

If your file system layout is different between the source and destination systems, then it is best to use %dump in your aliases. sql-sync would have to make an extra ssh call to get the remote temp directory.

You are right that the error reporting could be improved. I suppose there could even be an option to make the ssh call, for users who want to do it that way.

Yeah, I think a little better error message is sufficient here.

Thanks for sharing this one, In fact I had these kind of issue difficulties. Good that I have stumbled upon this blog, now I can make any changes with my configuration. Thanks and hope to see more of your updates.

Regards.
asset management

I have the same issue that hard for me to configure, my file system goes from different source and destination and still encountering issue on sql syncing. Could you please list here the step by step configuration. Thanks

Regards
Estudiar idiomas extranjero

Assigning to myself so that I remember to come back and improve the error message.

I just ran into this as well.

In my opinion we just need to fix it. The logic of using the same tmp dir on a remote machine is fragile to begin with, but we should at least try to find a writable tmp dir on the remote machine before failing. If that means a second ssh call to find that, I think it's more than worth it.

For a command like sql-sync that not enough people are using as it is, this is the type of UX issue someone will run into and then never try this command again.

Ok, this is a bit gross, but works for me going from osx->hardy.

Very open to cleaner approaches :)

In drush_sitealias_evaluate_path (which is used in rsync, but currently is not used in sql-sync), I make a remote call to drush core-status, which is has extended functionality to resolve paths such as %files. It is a little awkward to bolt this functionality onto core-status like this; it would be better to have some other drush command that was capable of evaluating paths. Then rsync could call it to get the value of %files, and sql-sync could call it to get the appropriate remote tmp directory.

Extra credit for also having a mechanism to create and return a temp file on the remote system to serve as a placeholder for the sync operation.

I'm willing to fix this at the sprint, but don't know if I'll have time before then.

Maybe #12 is close enough, since dump-dir can still be used to avoid the extra backend call. We could do #14 as a separate issue at a later time; I don't know that we need to be so exacting just to get this functionality.

This should get cleaned up for drush-5, either per #14 or by fixing #12 to use drush_invoke_process.

I'm OK with #12 if Greg is. Maybe add a line of docs to dump-dir saying that it speeds things up when provided.

Committed the attached patch which is #12, but using drush_invoke_process as suggested in #17. Let's handle #14 in another issue if we want to do that.

Marking for backport.

Thanks ... Could we add a little docs to dump-dir in example.drushrc.php? We need to state that it is faster if you provide this variable.

I think there might have been a bug in this or another recent patch. I'm getting screwy result from drush_sql_build_dump_command() where the temp filename is -123456789 where the numbers are a timestamp... I'll look at it some more.

Yeah reverted this patch and everything started working again. here's the remote command that's being sent by sql-sync:

Calling system(ssh -o PasswordAuthentication=no USERNAME@HOST 'if [ ! -s  ] || [ $((`date "+%s"`-`stat --format="%Y" `)) -gt 86400 ] ; then mysqldump --result-file -1324506920 --no-autocommit --single-transaction --opt -Q  dosomething --host=localhost --user=dosomething --password=XXXXX ; mv -f -1324506920 ; fi 2>&1');

Hmm, can you provide the options you used for that command and any command specific options in those aliases or your drushrc? I can't seem to reproduce that behavior.

I found some broken logic in that commit which I've just fixed. Please update and try again.

Yeah much better.

With this patch, sql-sync is now required to be on the remote side by default. Setting %dump-dir in site alias avoids this, but I doubt many folks will discover that. Not much we can do about this, AFAICT.

I don't think this should be backported in its current state.

Actually, I was wrong. If drush is not on the remote side we assume /tmp is writable on remote side and keep going. Life is good. OK for backport if Mark thinks so.

I think I fixed this a while back so that if the backend invoke call failed, it would revert to "/tmp". For a while it would try to write tmp files at "/" if this happened. I haven't tested this recently, though.

In any event, I tend to think it best to not backport.

I'm good with this fix just living in Drush 5. Someone can reopen if they feel strongly otherwise.