Multi-Site installation serves wrong sitemap

my OCD wouldn't allow to ignore correcting the title.

OCD?

Obsessive Compulsive Disorder ; )

Oh... I must have an OCD too. I cannot resist to correct the titles on Drupal. Do you think I must worry for that? ;-)

No, we can start a club. I'd think most who take drupal seriously have some degree of OCD : )

Perfectionists are people too!

introfini, do these two sites currently share their files directory? (check admin/settings/file-system)

Another solution is to make the cache file names unique for the site being served.
Prefixing the file names with the content of $base_url is not a good idea because the file names will get too long (and maybe in some systems they would not even acceptable).

The system adopted in the 6.x-1 branch is to calculate the MD5 of $base_url, use the first 8 characters, and concatenate it with the currently used language identifier.
If you are using the 6.x-1 branch, there is no need to actually use a different directory for each site; the possibility given to select the directory is for particular cases (so particular that I cannot even think of which one they could be :-)).

(my OCD forces me to correct even my errors)

I'm confused - if sitemap.xml has to live in the root of the site, in a multisite configuration how can prefixing the sitemap.xml file name or using unique files directories address this issue?

@DeeZone: The comment was about the cache files being used to cache the sitemap cache; it has nothing to share with the URL a sitemap must appear at.

just so that collision of file names does not exist

As far as I can notice, there are not two different site addresses that cause substr(md5($base_url), 0, 8) to return the same value.

Yes I agree Kiam, but running a multisite install with the same files directory is not at all recommended and will cause problems with other modules (user pictures) down the road as well. I almost feel like marking this as by design, but I'd like to confirm that this is written somewhere already in d.org documentation.

I am not saying that using the same file directory in all the sites of a multisite install is something to do, but that the module should not make the assumption that the files present in the directory it creates its own cache files refer to the same site. The module should also not take the assumption that the directory the user set for the cache files will contain only its cache files; if the module doesn't make the second assumption, then it should not make also the first assumption.

I could have a multisite installation, and not have any problem with sharing the same files directory between more sites. Should I be forced to use different directories, in that case?

I'm just following what core does exactly with respect to the files directory. The user pictures are not uploaded with the domain in their filename. They are all uploaded as picture-[uid].jpg, etc. If I run a multisite install with a shared files directory, and my user 3 uploads a picture on one site, my other user 3 on the other site will be surprised to see a picture he/she did not upload.

The promotion of using the same files directory for multiple sites isn't the right thing to do

I am not promoting anything; I just said that the module should not take some assumptions that could not be met. If the code I am using is able to work on multisite installation where a single files directory is shared among different sites, I am not going to report it in the module documentation, nor in the project page.

Then, I repeat myself; why doesn't the code take the assumption the user will reserve a directory only for XML sitemap? In that way it could delete all the files present in the cache files directory without to verify the name of the files being deleted. It would be faster to do, and it would require less code.

Then, I repeat myself; why doesn't the code take the assumption the user will reserve a directory only for XML sitemap? In that way it could delete all the files present in the cache files directory without to verify the name of the files being deleted. It would be faster to do, and it would require less code.

This is how the the 6.x-2.x branch currently works. This is how the entire Drupal core works with any folder in the files directory.

This is how the entire Drupal core works with any folder in the files directory.

Does Drupal core delete files in a particular subdirectory of the files directory?

http://api.drupal.org/api/function/drupal_clear_css_cache/6
http://api.drupal.org/api/function/drupal_clear_js_cache/6

I found a core optional module (color.module) that doesn't delete any directory content present in a subdirectory of the files directory; it actually creates a directory under files (color), but it doesn't delete the content of that directory.

"Excuse me but not using a different files directory per site is asking for trouble from all contrib modules and not just this one. The correct solution is to create a files directory in each of your sites/ directory. I even create a different tmp directory per site just so that collision of file names does not exist."

Absolutely!, that's the correct way.
I had a million problems on my multi sites until I created seperate files and tmp directory for each and every site.

Absolutely!, that's the correct way.

I agree on that; but in the case you would not correctly set the directory to use for each sites of a multisite configuration (there could be many reasons; maybe you forgot to do it) would you prefer a module that shows the same sitemap for all the sites of that configuration, or a module that at least is able to show different sitemaps for each site?

I am not saying that to use the same directory for all the sites of a multisite configuration is the thing to do, although it's not said that somebody is able to use the same directory for all the sites without to have any troubles.
The question here is if the module must take the assumption that the directory is used for just a site, or it's just used for its own files. As there aren't instructions about that for who installs XML sitemap, maybe the module should not take such assumptions.

waste of precious cycles

Provided that in the specific case the code is working, and it doesn't cause problems to the user, what is the waste of precious cycles?

Maintenance for a feature is in itself promotion of that feature.

As the feature is not published in the project page, nor in the project documentation, which one is the promotion?
If the user follows what it suggested him to do, he will never know the code will work also sharing the same directory between multiple sites; if he forgets to correctly set the files directory, he will not have the same sitemap served for different sites.

I have added an additional warning on the cache directory setting:

This folder must not be shared with any other Drupal site or install using XML sitemap.

As such and per the previous comments, I am marking this as by design.

At least, the user who cannot use a different files directory for each site of a multisite installation is warned to change the default directory containing the cache files used by XML sitemap.