Closed (won't fix)
Project:
Drush
Component:
PM (dl, en, up ...)
Priority:
Normal
Category:
Support request
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
9 Nov 2010 at 08:00 UTC
Updated:
22 Jun 2020 at 22:05 UTC
Jump to comment: Most recent
Comments
Comment #1
jonhattanDo you have
cvsinstalled?Also see the fresh new bug submission guidelines and paste here relevant information.
Comment #2
decibel.places commentedSimilar problem here, probably related to the Windows 7 Read-Only Bug
wget works but not the drush download so I can use the ftp version info in the error message to download the recommended version manually with wget:
HACKY!
I am currently in a corporate environment, and my User Account is tied to my employee ID so I can't just create a new user account. Checking attrib and UAC did not help resolve it. Also I have no "Public" folder set up on my machine. HEEEELLLLP I am stuck (waiting for our sysadmins to fix my local folders) inside a corporate whale!
Comment #3
greg.1.anderson commentedCan you recommend a better temporary directory to use on Windows? An easy way for drush to work around this problem would be to just use a different temporary directory, perhaps a per-user temporary directory, and thereby avoid the Windows 7 Read-Only bug altogether.
The relevant code is in
include/filesystem.inc; we just need to changedrush_find_tmp(). I presume that drush is using c:\TEMP as the temp directory because this is what sys_get_temp_dir() is returning. You will notice that drush first tries to use c:\windows\temp or c:\winnt\temp and will prefer either of these if they exist and are writable. As an experiment, I would recommend that you create one of these directories and give it appropriate world-writable permissions, and see if that clears up your dl problems.It would still be good to have drush switch to using another directory for Windows 7 to save other people from the grief this issue might cause.
As a final note, I will mention that hopefully everyone who is trying to use drush on Windows is using drush-5.x-dev; there are a lot of Windows bugfixes in master that have not been (and will not be, probably) backported to drush-4.
Comment #4
decibel.places commentedAll my directories on the filesystem have Read-only set and it cannot be unset through the properties tab or command line. As I said, it is a known Windows 7 bug. So switching temp directories does not work (but I have tried it).
Actually the relevant code is in function drush_find_tmp() in includes/drush.inc @ line 1600 - include/filesystem.inc does not exist in my Drush distro.
Able to download only:
by removing is_writable($directory) from:
so it reads:
I am able to download the tarball of the recommended version to the Drupal site's root directory for manual unpacking and placement in the modules directory, then I can enable it with Drush:
However in a different site it still doesn't work I get a simplexml_load_file() error:
My Drush Version:
Comment #5
greg.1.anderson commenteddrush-4 and Windows is an unsupported configuration. Any code changes to support Windows will have to happen in the 5.x-dev branch. Once we get a change into 5.x, we can discuss a backport, but only if it is possible to do more-or-less in isolation (does not depend to heavily on other Windows fixes that are not going to be backported).
Bummer that the ro bit gets set on every directory in the filesystem. Can I take it from your message above that the php function is_writable('path') returns FALSE for all directories, but it is possible to write to some directories even though is_writable claims that you cannot?
If is_writable('path') returns FALSE for all directories (on a machine exhibiting the Windows Read Only bug), is there some other sanctioned way to determine if the folder is actually writable? Do we have to do something like this?
Comment #6
decibel.places commentedtried the drush_is_writable() function
with the same result, tarball is downloaded to Drupal home directory
Drush 4.4 runs fine on my personal computer with Windows 7; I am having this problem at my work desktop where I have full admin privileges but I cannot reinstall Windows without tech support.
I tried Drush 3.3 and got errors:
Yes, I can write to the directories normally, but it seems that PHP is having a problem, and I am running PHP as administrator.
For now, downloading the tarball of the recommended version and manually moving it is the best I can do. I can use Drush on the remote LAMP server fine. It's just local dev that is a pita.
Tried Using Public Folders
I tried using the Windows Public folder as suggested in the article about the Windows 7 Read-only Bug and I even tried using my Dropbox/Public folder. No luck, they are also set Read-only, btw.
Comment #7
greg.1.anderson commentedSeems to me that since the Windows Read Only bug is caused by writing stuff to c:\, that it is unwise to store all of your sites there. However, if I understand the WROB correctly, once it happens, your whole computer is affected until the problem is fixed, and the normal workarounds are not working for you, so moving your sites probably won't help you unless you do a reinstall.
Regarding the undefined function filter_xss error, try the patch at #1174496: WSOD: drupal_error_handler() assumes filter_xss() is defined. It probably won't solve your primary problem, but will help avoid this spurious error when running drush in debug mode.
Comment #8
greg.1.anderson commentedNote that temporary directory improvements for Windows were committed as part of #955768: drush.bat lacks sandwich making in Windows. This may improve some of the symptoms above.
I'm not sure there is anything else we can do about the Windows Read-Only bug; please re-open with any additional information or proposed patches.
Comment #9
jhr commentednovice triaged - feel free to reopen