Bogus filesystem paths, warnings, and stale directories

Try upgrading to drush-5.x-dev latest HEAD.

Hope you don't mind if I join in

I was having the same error but using apache, php, mysql,gnuwin32, and more. Now I can now use "drush dl cck" thanks to using the latest head.

here's is my computer varibles C:\Program Files\Java\jdk1.6.0_23\bin;C:\Program Files (x86)\PHP\;C:\ProgramData\Propeople\Drush\;C:\Program Files (x86)\GnuWin32\bin\;C:\Program Files (x86)\cwRsync\bin\
:
________________________

DOS

C:\Users\paul\workspace\drupal.development>drush dl flashy
Project flashy (6.x-1.0) downloaded to [success]
C:/Users/paul/workspace/drupal.development/sites/all/modules/contrib/flashy.
Project flashy contains 3 modules: flashy_link, flashy_filefield, flashy.
file_put_contents(/tmp/cache.inc): failed to open stream: No such [warning]
file or directory pm.drush.inc:2401

OK after making a directory c:\tmp

___________________________
C:\Users\paul\workspace\drupal.development>drush dl cck
Install location C:/Users/paul/workspace/drupal.development/sites/all/modules/contrib/cck already exists. Do you want to overwrite it? (y/n): y
Project cck (6.x-2.9) downloaded to [success]
C:/Users/paul/workspace/drupal.development/sites/all/modules/contrib/cck.
Project cck contains 9 modules: userreference, text, optionwidgets, number, nodereference, fieldgroup, content_permissions, content_copy, content.

C:\Users\paul\workspace\drupal.development>

new problem here using this command. Drush is trying to locate a different settings.php file.
_______________________________________
C:\Users\paul\workspace\drupal.development\sites\drupal.development>drush en flashy
Command pm-enable needs a higher bootstrap level to run - you will [error]
need invoke drush from a more functional Drupal environment to run
this command.
The drush command 'en flashy' could not be executed. [error]
Could not find a Drupal settings.php file at [error]
./sites/default/settings.php.

C:\Users\paul\workspace\drupal.development\sites\drupal.development>

Attached patch fixes a full range of bugs:

1. dl attempts to delete empty directories, and excludes appropriate VCS directories to do so, but fails to pass the $force = TRUE parameter to drush_delete_dir(), which is required on Windows, since .svn/entries is read-only.
2. drush_find_empty_directories() fails to identify whether a directory is actually empty or not. Its current return value depends on the emptiness of sub-directories, which may or may not be empty.
3. drush_delete_dir() fails to pass the $force = TRUE flag into recursive invocations of itself.

Patch attached :)

Actually not really limited to Windows. I only happen to develop on that crap of an OS.

Looks good. Unit tests pass; committed to master.

Could be backported if desired.

yay! Thank you! :)

Won't apply cleanly due to filename changes. Reroll for 7.x-4.x, anyone?

Found some more instances of drush_delete_dir() that are missing the $force = TRUE argument over in #1231254-1: Add a suggested 'clone' alias to example.drushrc.php for cached git_drupalorg clones + allow to set 'home' option

Here are the follow-up fixes. That said, I wondered whether not all drush_delete_dir() calls throughout Drush should be wrapped in drush_op()?

mmm, any feedback on #12 ?

Sorry, been busy. The code in #12 looks good. Calls to drush_delete_dir should not be wrapped in drush_op; drush_delete_dir itself should wrap its operations in drush_op, like drush_copy_dir does. For some reason, it does not. :p

I should note that #14 is my opinion; drush is mixed on its handling of drush_delete_dir right now, so an argument could be made either way. In general, drush_op('drush_...'); is not done; drush functions tend to handle their own usage of drush_op. To whit:

$ find -exec grep -Hi 'drush_op(._*drush' {} \;
./commands/core/search.drush.inc:  drush_op('_drush_core_search_index');
./commands/core/search.drush.inc:    drush_op('_drush_core_search_index');
./commands/pm/download.pm.inc:    if (drush_op('_drush_recursive_copy',$request['full_project_path'], $request['project_install_location'])) {
./includes/filesystem.inc:      drush_op('drush_delete_dir', $dest);
./includes/filesystem.inc:  if (@drush_op('_drush_recursive_copy', $src, $dest)) {
./includes/filesystem.inc:      drush_op('drush_delete_dir', $dest);
./includes/filesystem.inc:    drush_op('drush_delete_dir', $src);

Except for drush_delete_dir, drush_op with drush functions is limited to a couple internal functions, ergo my conclusion that we should switch drush_delete_dir to work like other drush functions.

Interestingly enough, I noticed some calls to is_readable and is_writable wrapped in drush_op. That is simply odd; drush_op should only be used on things that change the persistent state of the system.

All tests passed; committed #12 to master. The drush_op stuff should be a separate issue, I think.

This was mostly for Windows, but #12 could be considered for drush-4.x as well.

Backported what was applicable from #12.