After the update has finished there is a sites\default\files directory created.

It does not looks completely wrong, not moving all drupal6\files content over, but why is drupal6\sites\default\files\languages and drupal6\sites\default\files\pictures and "drupal6\css" (???) created if this is not my sites files directory. Additional to this there is a de_bc87c4fd79ebbb2e0ce5e28ac07fbc4e.js file created in languages.

Sorry for reporting this only, but i haven't the time to look in and it looks very strange to me.

I tried this on IIS 5.1 with ISAPI_Rewrite 3.x.

CommentFileSizeAuthor
#18 update-files-default.patch887 bytesJirkaRybka
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Anonymous’s picture

Category: bug » support
Priority: Critical » Normal
Status: Active » Closed (works as designed)

This is not a bug, and is definitely not a critical issue. This is the correct action/directory structure and by design.

hass’s picture

Category: support » bug
Priority: Normal » Critical
Status: Closed (works as designed) » Active

Creating "drupal6\css" is not by design... this is a bug. It must be created inside the files directory as the others, too.

Anonymous’s picture

Priority: Critical » Normal
Status: Active » Postponed (maintainer needs more info)

Not a show stopper.

Please provide more information.
What are you upgrading from/to?
What database server and version?
What modules do you have enabled?

Please provide steps to reproduce the error.

Gábor Hojtsy’s picture

Hass: the update should leave your files directory and setting intact and it should not create the sites/default/files directory, neither create subdirectories or files there, neither change your settings. I'd watch for how your settings are used in the update, whether there is a level of bootstrap done there as required to use the settings from the variables table properly or not.

hass’s picture

Priority: Normal » Critical

Look inside the title. If my installation get crippled - is this critical or not? I think so.

hass’s picture

Status: Postponed (maintainer needs more info) » Active

@Gabor: Ok, then we have a bug fore sure. Upgraded and the directory has been created in sites/default/files, nevertheless "files" already existed. Additional a "css" folder has been created in website's root what is totally wrong, too.

I clicked the admin page link after upgrade... may give an idea...

catch’s picture

Only thing I can think of is system_requrements() now gets called from update.php since http://drupal.org/node/200674 went in.

  // For installer, create the directory if possible.
  if ($phase == 'install' && !is_dir($directory) && @mkdir($directory)) {
    @chmod($directory, 0775); // Necessary for non-webserver users.
  }

Any chance this is firing?

Gábor Hojtsy’s picture

Title: D5->D6: files path not updated » D5->D6: files path not carried over

Better title.

webernet’s picture

Is it possible the directory was never recorded in the variables table and was instead using the default?

hass’s picture

Drop'ed my D6 DB and imported D5 DB again and checked the variables table: 'file_directory_path', 's:5:"files";'. Looks good.

Upgraded again and it works. Drop'ed again and upgraded again, works. Drop'ed again and upgraded again, works. I'm sorry, but i cannot reproduce this anymore. If something goes wrong once it should be reproducible, but i have no clue what's happen here and why it works now. :-(((

catch’s picture

Priority: Critical » Normal
Status: Active » Postponed (maintainer needs more info)

OK I'm sticking this back to normal and active (needs more info) until someone can reproduce (obviously hoping that they can't). hass, nice one checking it again so thoroughly.

JirkaRybka’s picture

I seem unable to find any update function for the case of a 5.x site without files path setting (i.e. running with the default, without having a variable set). Do we have one, somewhere? And do we need one, is it possible to have 5.x site without the variable set? If so, then the changed default in 6.x needs to be accompanied by some update function.

Gábor Hojtsy’s picture

JirkaRybka: yes, that's a possible case for a problem here. The files variable is only set if the user ever submitted the files setup page (which the site status report page tried to press people to do :) or done some similar action in a contrib module, but that is not ensured. We can check if there was no files variable and set it to the old default to make sure everything will be fine.

hass’s picture

I used my production backup for this test... This install have set a files directory for sure as reported above. Shouldn't be the problem i found...

scor’s picture

I can confirm that the update should not create sites/default/files.
@catch #7: mkdir($directory) is not executed since$phase == 'install' is false. I checked during an update, and sites/default/files was never created. It is created during the install only. Also when visiting admin/settings/file-system (without submitting), Drupal will try to create the directory which is in the current file_directory_path value: sites/default/files on a fresh D6, or files or whatever you had in your D5 database if you've updated.

catch’s picture

@scor, yeah that's what I figured but stranger things have happened, seems to have been a fluke on hass' system rather than something reproducable anyway.

Gábor Hojtsy’s picture

It would still be good to ensure there is a files variable setup on upgrades, if there was no files variable before. So that the new default is not used.

JirkaRybka’s picture

Status: Postponed (maintainer needs more info) » Needs review
FileSize
887 bytes

I've rolled a small patch for this. Tested on my real site (using the dafault 'files' path), with the variable manually removed (via PhpMyAdmin, pre-update of course).

Gábor Hojtsy’s picture

Status: Needs review » Fixed

Looks good, committed, thanks.

Anonymous’s picture

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.