I just went on my site a minute ago and noticed this error:
I’ve never seen this error before and don’t quite know why I am all of a sudden seeing it.
The error goes away after 10 seconds and as I navigate around my site I don’t see it again. If I clear my browser cache, cookies, etc. I see the error again.
Does anyone have any ideas why this is coming up?
Thank you,
Brandon
Guess: It is trying to create a directory in a directory where you have exceeded the number of files allowed (underlying server).
If you want to know specifics, you will need to modify line 114 in core/fn.fs.php to read something like:
if( mkdir($path, $perms) === false )
echo "
$path";
This will probably reveal that it is trying to create a subdirectory in your images directory because there are too many there…
Was that meant to be a fix? I thought it would tell me more of what is going on, but now that I’ve put in the code you provided I can’t get the error to come back up.
I am wondering a couple of things though.
First, why is the cart trying to make images or directories on the customer side of things? I understand the cache and stuff, but this doesn’t seem to be related to that.
Also, I’m wondering if one specific product is causing this error. I use the random addon for my featured products so the products change each time I refresh my page. Maybe the conflicting product was up when I got the error, but now that it is out of rotation I don’t get the error. This kind of makes sense to me since I don’t see this error on any other page besides the homepage. What do you think?
Thanks for the code though.
Brandon
Hi Brandon,
You are also getting this message when you go to check out or view your cart.
Warning: mkdir() [function.mkdir]: Too many links in /home/saltwate/public_html/core/fn.fs.php on line 114
var/cache/schema_promotions_schema
My cache was 1.6 MB. I’m not sure how big this is supposed to be, but I deleted it and as far as I can tell I don’t have anymore problems. Of course I thought I was rid of my problems earlier.
I’m not sure what schema_promotions_schema is for, but maybe there was a conflict of the cached file and the “good” file. I’m also running smartoptimizer so mayber there is a conflict there, but I doubt it.
Brandon
No, is not a fix, just something to try and help understand what is causing it (which file, product, etc.).
My understanding (possible missunderstanding) is that in 2.1 images are restricted to 1000 (maybe 10000) per directory. When the system tries to create a new image (like a dynamic thumbnail) it looks at the numberf of images (based on current directory name and image_id) and if needed, creates a new directory to store the new images.
This can happen in admin when uploading images or in real-time for created thumbnails.
Images are named /images/product/3/foo.jpg where ‘3’ is the created sub-directory.
I would have done this off of a hash table rather than waiting till a directory is full before creating the sub-directories…
This isn’t a common php error Brandon unless you have 32,000+ items in a directory where the script is attempting this function.
If not then this could be caused by a previous error that isn’t being shown or could also be corruption of a partition. You may want to ask your host to investigate this
Thanks for the input Scott and Tony, I appreciate it.
I still don’t fully understand the images thing, but it seems my problem is gone.
I think that it had something to do with my cache.
For now I’m thinking that I’ll just leave it be and see if the problem comes up again unless you guys think that is a bad idea.
Thanks again,
Brandon
I like to understand problems wherever possible…
The mkdir() failure is happening in the fn_mkdir() function. Without knowing what path was trying to be created, it is impossible to determine if this is something caused by your cache, by your environment or by some other event.
Uhm, well I didn’t quite get that, sorry. It’s late and I’m tired so that is probably why.
Anyways, I think the path that was trying to be created was
var/cache/schema_promotions_schema
Of course I don’t actually know if that is what you are talking about or not.
Brandon
That would be even more distrurbing…
Assuming you use the ‘file’ value in config.local.php for the $config[‘cache_backend’] value.
I believe in 2.1 that many cache entries are in sub-directories now like promotions, features and filters. I don’t run the back_end as type file so I can’t check…
Suffice to say this would get fixed when you cleared your cache then… But that it’s happening in the cache directory at all is disturbing. I would report it as a bug. Having corrupt data is not a good place to be.
In config.local.php you might want to change the value of $config[‘cache_backend’] to ‘mysql’.
A word of warning Tony, I’ve had multiple clients with busy stores that have had problems with the mysql caching method. That table fills to capacity then throws errors preventing the script from loading.
I hear there is another release planned very soon with additional cache fixes but I really wish they would provide a way to completely deactivate it altogether so server side caching is more effective. Clients on Lightspeed or Apache servers using additional opcaching would benefit greatly without the CS-Cart internal caching.
I hear your warning… In my experience, the shear number of files involved in their current caching scheme puts a huge load on the underlying server. I host a number of stores and the file caching method simply kills the underlying server once any real activity starts on a site (3-4 simultaneous users).
I am not running any production stores on 2.1. I won’t go there till at least 2.4 when I would think things might be approaching a point of stability.
I use the PDOsqlite caching in 2.0.15 (my production versions). The only issues I’ve encountered is that for some reason, not all admin data changes get written through (like close/open store or changes to promotions, etc.). So my clients need to flush their caches after making admin changes. I have not been able to get sqlite caching to work under 2.1.
The performance improvement is HUGE relative to the total server load.
Under 2.1, I would have thought that the mysql method would be okay (even through much of the cache is caching mysql requests to begin with). But if the caching scheme causes problems in mysql then I’d assume it would cause equal if not greater issues in files.
There are two major issues in performance/caching that need to be addressed from my perspective:
- Stop caching things like filters and features. Or if you do, cache the whole item versus each one individually. A client with 2K products and where those products have multiple features ends up with thousands of cache entries, one for each product and feature combination (scaling up again for each language). Same goes for filters. Build them once and keep them in an well indexed table. Take the hit when a product, category, feature or filter is saved rather than trying to resolve it when the customer accesses it.
- Stop using AJAX on page loads. AJAX is intended to be a user-initiated item (like selecting from a drop-down to fill another). It is not intended to be a multi-threaded backend to help with load times for a single user experience. If you’re going to use it to fetch data in parallel then do it in a very effecient manner. I.e. don’t load all the addons and other overhead to do a simple DB query returning the results in an HTML select statement.
The QA cycle needs to utilize load testing. I.e. synthesize 10 simultaneous users and see what happens to the system. That will (with current methods) bring a server to its knees.
My two cents…
To get a sense of what I mean, drop the following code into addons/my_changes/controllers/customer/init.post.php
```php
define('URL_LOG', DIR_ROOT."/url.log");
define('DATE_TAG', date('[m/d/Y H:i:s]'));
define('EOL', "\n");
define('COUNTER_NAME', 'urlLog_counter');
if( empty($_SESSION[COUNTER_NAME]) ) {
$count = $_SESSION[COUNTER_NAME] = 1;
} else {
$_SESSION[COUNTER_NAME] += 1;
$count = $_SESSION[COUNTER_NAME];
}
file_put_contents(URL_LOG, sprintf("%s %d - %s%s",
DATE_TAG,
$count,
$_SERVER['REQUEST_URI'],
EOL), FILE_APPEND);
?>
```
Then just view a single page. On my system, I see 4 calls to this controller. First is for the initial page, second is because I have send to friend enabled so it spawns a whole other thread to get a verification ID (twice for some reason) and then it calls the statistics page.
Activity will be in the file named ‘url.log’ in the root of your store.
Note that for each of these, addons are initialized, all the classes are loaded and initialized, the registry is read (and written when complete), etc.
So in this case one is getting 1/4 of the throughput they should. Statistics should be captured in-line (no need for separate process) and same with captcha (should be retrieved once and stored in the SESSION)… Of course, if there are filters and/or features, then it generates even more processes. If there are multiple languages then it could generate even more.
Note that the repeating counter (36 in this case) are all AJAX requests.
A redraw of a single product detail page on my test system generates:
[10/25/2010 14:55:27] 35 - index.php?dispatch=products.view&product_id=4
[10/25/2010 14:55:29] 36 - /index.php?dispatch=image.captcha&verification_id=51aldqe0efa8it0tum3fpdpfu3:login_login_popup_form&login_login_popup_form4cc60adfc994b&
[10/25/2010 14:55:29] 36 - /index.php?dispatch=image.captcha&verification_id=51aldqe0efa8it0tum3fpdpfu3:send_to_friend&send_to_friend4cc60ae0021df&
[10/25/2010 14:55:29] 36 - /index.php?dispatch=statistics.collect
So why doesn’t a developer do something like this or at least a QA person? Let this run while you go through a normal navigation of your site and then review. You’ll see all the needless activity that is happening.
I am getting the same message on top of my page too.
Warning: mkdir() [function.mkdir]: Too many links in /home/howardmi/public_html/core/fn.fs.php on line 114
some times more than 3 or 4 times repeated at the top of the page. I clean the cache and goes away. But this is not good, I am doing heavy advertising. and looks like when there are lots of traffic coming to the site this happened.
I noticed that even google indexed that too for my website.
I hope there they will come up with the better solution.
Have you installed the sqlite caching for the Registry or are you running “standard” with the files method.
My bet is that you are using files and that you have a lot of filters and/or features configured in your system.
I would suggest using the PDO sqlite version of core/fn.registry.php. The only downside is that you will have to clear your cache more frequently when makiing changes from the admin panel but the performance will be better and I don’t think you’ll get the errors.
There’s a thread in the bugtracker (I think) for this, otherwise, search fhe forums for (PDO or sqlite). If that fails, PM me and I’ll put up a link to it on my site. If someone else has reference to Zeke’s modified Registry for 2.0, please post it here.
[quote name=‘tbirnseth’]Have you installed the sqlite caching for the Registry or are you running “standard” with the files method.
My bet is that you are using files and that you have a lot of filters and/or features configured in your system.
I would suggest using the PDO sqlite version of core/fn.registry.php. The only downside is that you will have to clear your cache more frequently when makiing changes from the admin panel but the performance will be better and I don’t think you’ll get the errors.
There’s a thread in the bugtracker (I think) for this, otherwise, search fhe forums for (PDO or sqlite). If that fails, PM me and I’ll put up a link to it on my site. If someone else has reference to Zeke’s modified Registry for 2.0, please post it here.[/QUOTE]
I have tried this and it made the site very slow so i had to revert to file.
Now we have to keep clearing the cache every few days (yes we have a lot of filters).
Anyone else has suggestions?
Quite surprised that your experience is that sqlite is slower than the files method… Not heard any report of that, especially for those sites that have large numbers of filters or product features.
[QUOTE]I have tried this and it made the site very slow so i had to revert to file.
Now we have to keep clearing the cache every few days (yes we have a lot of filters).
Anyone else has suggestions?[/QUOTE]
People really need to strongly consider adding the version of CS-Cart they are currently using within their posts as this is going to get real confusing real fast considering all of the changes made to the cache system over the last 2 or more releases. 
For example I would not be surprised if someone ends up installing Zeke’s SQLLITE beta fix in a later version CS-Cart release which now has this installed in the core release! 
So I’m trying out the trial. I currently have the same error message as the original message.
What exactly is the answer? I tried making the folder in the vars folder. No go.