I can run drush on windows. I added wget tar and gzip to my path and the update command worked when drush was included as a module inside of the drupal install.
Now that i'm using a common install and specifying the path to the drupal site with -r i can't run the update command.

I tracked it down to the untar step. tar is run with the -C option to set the output directory. tar fails to understand absolute paths on windows so when i specify the site root as C:\Users\Ed\Websites\Drupal it tries to use C:\Users\Ed\Drush\C:\Users\Ed\Websites\Drupal. This is a problem with tar. (http://gnuwin32.sourceforge.net/packages/gtar.htm) but i found that the tar included with msysgit is from (http://www.mingw.org/) and that tar works just fine.

I have also tried using a relative path the -r option ..\websites\drupal and drush can't find everything about my drupal install.

So I'm recommending that we change the README/documentation to have windows users install msysgit and just download wget because gnuwin32 tar is screwed up.

-Ed

but everyone wants to use git anyway right?

-Ed

Thanks for the tip, I had the same problem

 Title: GNU Tar on Windows » Update fails silently on Windows (GNU Tar on Windows) Component: Documentation » Code Category: support » bug Priority: Normal » Critical

I am bumping this to a bug, since drush wrongly returns "Project X was updated successfully. Installed version is now new_version", instead of reporting the error. You only see the tar failure when you run with the verbose flag.
Thanks for the tip on the msys tar. It is version 1.19.90. The one that comes with GnuWin32 is version 1.13. I found all I needed was the new tar.exe and msys-1.0.dll.

Usually I am to the point, but this time I'll give the full story, to give some hints how to improve usability. It took me half a day before I could use drush succesfully on my Windows.
I knew that Drush existed but never used it, as I couldn't imagine why I would want to use commandline utilities
with Drupal. Then I read the book "Leveraging Drupal" from Victor Kane which mentioned the use of Drush for updating modules with Drupal projects maintained in SVN. That is nice, I thought, let's try. So I downloaded Drush, put it in my sites/all/modules folder and went to admin/build/modules. No Drush there.
Weird, let's read the documentation (usually I do before installing a module, really!). Ah. so it completely changed and has to be outside the webroot now. Why is it still under Drupal modules then? But anyway.
I had studied how to create an alias for drush on Windows already and found two solutions, one with cygwin and one with powershell. Not really necessary because just adding it to the Path and changing the drush.bat a little
(adding the full path to drush.php) worked fine.
First I tried a database export. The result was three times smaller than my exports I usually do with phpmyadmin, impressive or worrying? So I compared and found out that this is mainly caused by using less spaces.
Now I went for the main thing: updating modules in my SVN with Drush: drush pm update --svnsync. Strange,
no mention of --svnsync in the help (typing drush help update). Also pm seems not be working anymore, although there is a pm folder. What is pm? pm=package manager, I read.
drush update --svnsync seems to work. It finds some modules to update, replaces them with downloaded files but an error at the end when doing the post update. Ok, it was mentioned that drush was experimental for Windows, but don't worry I can update with update.php.
But what is that? The modules were not updated at all! Ok, let's try "drush updatecode" instead. Here the help mentions --svnsync also.
It seems to run smooth, but again no modules updated. What the heck? Some investigation in reported bugs on the drupal website learns that it could be the tar.exe version.
so I run again, this time verbose with -v and indeed I see the problem with tar using wrong paths. A newer tar.exe from msys seems the solution. By mistake I downloaded the complete MinGW, heck I don't want to install 100MB only to replace tar.exe. So I took out only tar.exe and msys-1.0.dll but where to place them?
I did a search on my laptop and found several tar.exe, so I decided to put them into my system32 folder. Seemed to work: no error messages anymore when running drush update verbose. But again, no updated modules. So let's check the tar version with tar --version. Nothing.
Something was wrong with tar.exe. Ok let's install complete msys then. Ah. only 6 MB. Running msys, wow that is an ugly shell. Indeed, now I have a newer tar.
But new problems: it does not recognize my path to drush and does not like the statement in the drush.bat. So I try directly with drush.php: and yes, finally a recipy that works! pff...

PS I don't know how many Drupal users find out about Drush by reading Victor's book, but if it is a substantial part it may be a good idea to add a note about the changes since the book publication on the drush front page.

Docs patch is welcome. So is a patch which somehow checks that user has a compatible tar.

There are two issues here. The Windows/tar path issue and the silent failure.

The failure is silent because the return status of the gzip and tar commands in wget.inc are not explicitly checked. There is a later test that attempts to determine success, but if I'm reading it correctly it only checks to see if the directory exists. In the case of an upgrade the directory already exists, so the test will report success whether the upgrade is successful or not.

If I am understanding the code correctly this is a problem regardless of platform. Possible Unix examples where this could be a problem are file permission issues or lack of disk space. Both would prevent tar from updating the module files.

<?php  // Decompress  drush_shell_exec("gzip -d " . $filename); print "Just passed shell exec on gzip\n";$tarpath = substr($filename, 0, strlen($filename)-3);  // Untar  drush_shell_exec("tar -xf $tarpath -C "$path"");  // We're not using tar -xzf because that's not working on windows...   // Remove the tarball  drush_op('unlink', $tarpath); // 'drupal' project gets tarred as drupal-6-10/foo instead of drupal/foo so must be excluded from test below. // Translations get untarred into the Drupal root, so there is no easy way to check. if (!is_dir($path . $project) && !drush_get_context('DRUSH_SIMULATE') &&$project != 'drupal' && $info['type'] != 'translation') { return drush_set_error('DRUSH_PM_FILE_UNTAR_ERROR', "Downloaded file$filename couldn't be untarred correctly");  }?>

Would downloading/uncompressing the tarball in a temp directory then copying the files to their destination be a viable alternative for handling this? It would eliminate the requirement for "tar -C" and if something hickups the files are in a temp directory and easily cleaned up.

Same issue with the windows tar path, tried the tar that came with msysgit and I am still having the same issue you described.

Executing: tar -xf cck-6.x-2.5.tar -C "C:/Documents and Settings/Administrator/Sites/acquia/acquia-drupal/sites/all/modules/"  tar: Cannot change to directory C:\Documents and Settings\Administrator\Sites\acquia\acquia-drupal/C:/Documents and Settings/Administrator/Sites/acquia/acquia-drupal/sites/all/modules: Invalid argument  tar: Error is not recoverable: exiting now

Looking at the code it looks like we are having a problem not with tar(which it still might be), but with the logic in pm.drush.inc, specifically pm_dl_destination_lookup. It should be telling tar just to switch the directory to "sites/all/modules" not \$sitepath.'/modules' as that returns that entire file path.

I'll do some more testing later but while making this change does let me install modules on my local install it will give me problems elsewhere. I guess what I am wondering is is this really an issue with tar or with the code for the module itself?

This issue is the collision of two factors:

• Drush wants to handle file paths in an OS independent way but hasn't truly abstracted the file handling (for good reasons)
• MS Windows does not consider the drive label a part of the file path

The errors you see with GNU tar are a result of passing it a path with the drive label included (e.g. c:\foo\bar). I suspect it's calling a Windows change-directory function to cd to the directory and failing on the "c:". It appears that the alternate tar utility knows how to handle this.

I played around with removing the drive label from the file path in Windows and it works in most situations. It has the side effect of limiting the utility to working on the currently active drive.

A straight forward solution in this situation may be untarring the file in the current directory and using PHP to copy the files to the module directory, instead of untarring directly into the module directory.

Could it change tar to other software on Windows ?

http://pear.php.net/package/Archive_Tar
l10n_server using it. and works on windows.

or

7-zip, this is open source and free (I patch my drush and works well at windows. nice performance)

I would be OK with a patch that untars into a temp dir and then copies files with php

I'd love to receive a patch quickly and then issue a 2.1 release of drush. If not, this will wait.

I tried to write this patch. But since sys_get_temp_dir() returns a path with the drive letter in it, the same issue comes up. I think changing the documenation is the way to go.

Of course the error needs to be visible even if not in verbose mode.

I added a child page to the drush main documentation on installing on windows: http://drupal.org/node/594744

 Status: Active » Closed (fixed)

Nothing to do here. Feel free to submit README patches.

I ran into this problem just now.

The msys tar.exe has issues to. The tar.exe from GIT works ok for now

Inside here: C:\Program Files\GnuWin32\bin

make a copy of the bsdtar.exe and then rename it to tar.exe.

Now i am able to untar files in the pm-update.