Remove symlink creation. Let each path have own file

What would be the best point to attack this, i.e. to store cached content files on the disk instead of symlinks for windows servers?
Changing the function _boost_symlink in boost.helpers.inc?
Or would each symlink-related code in the boost.module itself to be altered to accomplish this?

If i get a hint, i could try this fix to make boost available to windows server, too!

status: need more info

Yes, a setting for whether to use symlinks, or not, does sound pretty all right in principle. The problem, however, is that Boost presently really relies on the presence of symlinks, and adding non-trivial special cases at a good number of places in the code is akin to obfuscation.

I think it would be preferable that your patch would try to abstract out the OS-specific parts somehow; for instance, you could first look through the code to find out which functions rely on symlinks, and then separate those bits out from boost.api.inc into, say, boost.unix.inc and boost.windows.inc, or something like that. Then we could make do even without an explicit setting, just checking the current operating system in order to see which file we should load into boost.api.inc.

If you do proceed on this front, please make sure to adhere to the existing coding conventions in the code, and submit your results here in the form of a patch. Also, please be aware that I don't myself have any Windows machines available for testing, so in practice you yourself would need to support and further develop the Windows bits as necessary; if you're willing to do that, I would make you a co-maintainer of the Boost project here on drupal.org so that you can take ownership of any Windows-specific issues and such.

Hey Arto,

sounds reasonable and good.
I could do the code changes and provide a patch, and even maintain the windows parts.
However, i don't know the guts of BOOST very well right now, so a little hint to the spots of the code that are os-/symlink-dependent would be great!

As far as i can see, the following places in the code would have to be altered - is any other part of the code symlink-dependent?
(based on 5.x-1.x-dev from 2007-Aug-07)

~line 94:
$symlink = boost_file_path($alias);
if (is_link($symlink))
@unlink($symlink);

~line 142
// If a URL alias is defined, create that as a symlink to the actual file
if ($alias != $path) {
$symlink = boost_file_path($alias);
_boost_mkdir_p(dirname($symlink));
if (!is_link($symlink) || realpath(readlink($symlink)) != realpath($filename)) {
if (file_exists($symlink))
@unlink($symlink);
if (!_boost_symlink($filename, $symlink)) {
watchdog('boost', t('Unable to create symlink: %link to %target', array('%link' => $symlink, '%target' => $filename)), WATCHDOG_WARNING);
}
}
}

Can you explain in a few words to me what the second code fragment does, and what to keep in mind when chaning it to a windows-version?

Then i could extract the os-specific parts of the code into a boost.OS_NAME.inc file that would be automatically included for the running os, just as you suggested.

Hey Arto,

windows support via os-dependent inc-files for BOOST is done (using file-copies instead symlinks in the windows version, tested on windows).
Find attached a zip with the patches and the new additional os-dependent inc-files - oh, and remove the ".txt" extension, since i added it just to be able to upload the file.

hope to hear from you,

daniel

Hey Arto, any news on integration of the windows-compatibility feature for Boost??

Hi Daniel,

Currently at DrupalCon, but will try and review your patch next week when I get back home.

windows does actually support symlinks but only for directories - not files. so one option would be for boost to produce many directories all with a single index.html inside. this is a bit less clean than the current solution but straightforward windows compatibility using same code is very nice.

we would make a wrapper around the symlink() function in php so it shells out to the 'junction' program in windows which created symlinks. see _symlink() in the comments at http://us.php.net/symlink for an example wrapper. the junction program for windows is available for free at http://www.microsoft.com/technet/sysinternals/FileAndDisk/Junction.mspx

Moshe, that's a very interesting idea. I'd love a patch that worked the way you describe.

Hmmm. Caching to alias-named files instead of using symlinks would take care of the "too many files in your /node/ directory, you're killing our server" problem, here: http://drupal.org/node/171444

I think it's more elegant (it removes one level of complication), but it's possible that I think so because I'd need to get around the 171444 problem, too; I have 30+k nodes.

From bjaspan:

It seems to me that the symlink code is unnecessary complexity on Unix and extra logic to work around not having symlinks on Windows is even more unnecessary complexity. Just write the HTML out to whatever path was requested! So we end up with two copies of some pages if people go out of their way to access node/nid. So what? Disk is cheap.

I agree so I set this issue to 'needs work'. Feedback welcome.

This fixes Windows compatibility so thats why we keep discussion in this issue.

Note that globalredirect.module is useful for assuring that noone goes to node/nid URL. I see little value in the symlinks considering how popular that module is.

Here is my patch to stop using symlinks. I only stop calling _boost_symlink(), I haven't actually removed the helper function yet.

If one were to use this patch this means i18n should now work as well, correct?

@justafish: Yes! i18n works with this patch.

fixes my issues with i18n as well.

i also feel that the problems introduced by symlinks wrt. interop with other modules outweighs the relatively minor benefits.

i take it back, i still have an i18n issue.

let's say that default language is en
if the user requests a page like http://www.example.com/de
then boost_set_cache is called with $path=''
and drupal_get_path_alias('') returns 'de'
boost creates two cached files: index.html and de.html

now, if a user comes in with no default language setting, they will receive the cached german index.html

however, i don't think that invalidates this patch. this issue is about disabling symlinks, and the patch works perfectly for that. i18n support is a separate thing.

Daniel,

Is this module working for windows? What changes did you have to make in regards to clean urls? We are using ISAPI mod rewrite 3 and I am not sure how to change the configuration file to make this module work on a Windows 2003 server. Help!

-Drew

Hi,
Will you apply this patch if i provide you with windows and linux compatible patch?