September 12

Most of the time, when I do a Google image search, and pick on an image, it takes me to a page where I can choose to see the picture alone, go to the web page for that image, etc. Here's an example: [1].

If I don't want to do anything else with it, I can always hit the back button.

But, occasionally, I go to an image preview and it seems to hijack my browser, taking me immediately to the web page, like this one: [2]

The worst part is, I can't just hit the back button, or it goes right back to the same web site. If I hit the back button many times really fast, sometimes I can go back, but maybe too far.

So, what's going on here and how do I stop this behavior ? Does it do this for everyone else, too ? I'm on windows XP SP3 using Firefox 15.0.1. StuRat (talk) 06:35, 12 September 2012 (UTC)[reply]

AFAIK it's just poor website design of that particular page, nothing to do with Google. Best way to go back is to right click the back button and select the page you want from the drop down list. Even better, go into your Google search settings and check the box that says "Open each selected result in a new browser window" then you can just close the window when your done.--Shantavira|^{feed me} 08:11, 12 September 2012 (UTC)[reply]

Those are both good hints, thanks. But is there any way to stop it from doing this in the first place ? StuRat (talk) 08:54, 12 September 2012 (UTC)[reply]

The way I have always understood it is that the page itself has code designed to "escape" from Google, implemented in Javascript. An extension like NoScript will stop it, but I'm not sure if you can configure its filters to apply to just the situation of previewed pages in Google image search. 209.131.76.183 (talk) 11:39, 12 September 2012 (UTC)[reply]

I don't know if this is relevant, but the name of the webpage gives something away: ... The framebuster bit suggests the code is called from the url itself, or something like that. I don't know if that helps, and maybe someone can enlighten me as well about what exactly a url can control. Btw, I tried pasting the whole site name, and got spam blocked, because the site is on Wikipedia's blacklist IBE (talk) 04:31, 14 September 2012 (UTC)[reply]

Yea, I found a way around that in my 2nd link. Wikipedia spam-blocks "squidoo", so change it to "octopusoo", which apparently is a mirror site. :-) StuRat (talk) 04:40, 14 September 2012 (UTC)[reply]

Code and explanation (and claim of being the original creator) . Ssscienccce (talk) 07:34, 14 September 2012 (UTC)[reply]

Thanks. Now how do I prevent this from working on my PC ? StuRat (talk) 18:04, 14 September 2012 (UTC)[reply]

In a computer with 48 SAS HDDs, the device names for the first 26 HDDs would be /dev/sda to /dev/sdz. What would be the device names for the remaining 22 HDDs? Now I don't actually have a computer with four dozen HDDs, nor am I planning to buy or build such a computer (presuming such a computer even exists), but I'm very curious to know. (Presuming that all the 48 HDDs are directly connected via HBAs, and there is no hardware RAID.) 08:04, 12 September 2012 (UTC)

Can you actually connect 48 hard drives ? I doubt that any normal PC has the ports, power supply, etc., to support anywhere near that many. I suspect you'd need to go to

network attached storage at some point. StuRat (talk) 08:10, 12 September 2012 (UTC)[reply

]

I know Dell sells rackmount computers with 24 HDDs, and Supermicro has a chassis for 36 HDDs, but I've never actually come across a computer with 48 HDDs, but my question still stands. Although I think 36 HDDs is probably the upper limit for a single computer, as no PSU could provide enough power for more than 36 HDDs - the chassis I've linked above has two PSUs because one probably isn't enough to provide enough power for 36 HDDs. 27.104.34.139 (talk) 08:40, 12 September 2012 (UTC)[reply]

Beyond the standard few, device nodes are created by whatever thing is managing the large scale storage. The names typically follow the pattern: sda, sdb, sdc, ..., sdz, sdaa, sdab, sdac etc. ref. What the kernel cares about is device nodes, and the storage manager would have to create nodes in a fashion (with mknod/makedev) that the kernel and its block device drivers will recognise. For basic SDx, the major number is 8, and you have 256 entries for minor, but as that document shows, it reserves 16 minors for each physical SDx (for its partitions, SDx1, SDx2, etc.) and so has to use multiple majors to handle >16 physical disks. It's up to whatever enterprise-y storage manager and its drivers (for e.g. the FC fabric HBAs) to agree between themselves what majors and minors they'd use. -- Finlay McWalterჷTalk 09:56, 12 September 2012 (UTC)[reply]

By the kernel's standard counting, the system can just keep adding letters forever - the relevant piece of code is here. But I think we still have 8 bits each for major and minor, so you won't get very far with actual dev nodes. -- Finlay McWalterჷTalk 10:51, 12 September 2012 (UTC)[reply]

If a program does not run well under WINE, what can you do to improve it's compatibility? I'd like to run PDF-XChange Viewer, which is said to work well for some people, but I crashed with some specific pdf files or some commands (like find). OsmanRF34 (talk) 13:16, 12 September 2012 (UTC)[reply]

Determine which DLL seems to be the source of the crash. If you have access to do it legally, you can replace the WINE project's version of the DLL with one from an actual Windows system. If you know enough about software development, you could figure out which specific API call is causing the problem and try to debug the WINE source for it, improving the project for everyone. Comments on the winehq entry for PDF-XChange Viewer seem to imply that you may have luck running the portable version of it. 209.131.76.183 (talk) 15:02, 12 September 2012 (UTC)[reply]

You should consider the possibility that it might crash on those files in Windows as well. I'm not asserting that it does, but if it does, trying to fix the problem in WINE would be a waste of time. Looie496 (talk) 18:12, 12 September 2012 (UTC)[reply]

Look at the appdb.winehq.org page on the application, note the application (viewer) and Wine versions. For more problematic applications (that are also somewhat popular), there are also often detailed instructions for making things work. ¦

Nixxy00 (talk) 14:21, 12 September 2012 (UTC)[reply]

A good first step would be to confirm that the URL for the broken image file seems to match up with where your images are uploaded. That should help narrow down possible causes of the problem. If you try to open the image file directly via that URL you may also be able to get an HTTP error code. Right now I think the most likely problem is that there is a path configured wrong somewhere, so the links don't point to the same place the images are uploaded to. There could also be a file system level permissions issue, but I doubt it since the server should have uploaded them with permissions that allow it to read the file later. 209.131.76.183 (talk) 14:58, 12 September 2012 (UTC)[reply]

Thanks for the advice, i just tried that, when putting complete file path into the URL e.g. blah.com/wiki/images/9/imageiwant.jpg i get a server 403 error, saying i don't have permission :S BUT if i ftp an image into the file above e.g. /images i can access that though the a URL and it display fine, its weird because wiki uploaded the images (with correct height/width and image size) and put them in folder images/9 or images/9e etc but now cant seem to pull them out :S — Preceding unsigned comment added by Nixxy00 (talk • contribs) 16:06, 12 September 2012 (UTC)[reply]

That makes it sound like the file permissions are being set wrong by the uploader. You should see what your FTP client says the permissions are on the file. I suspect that there is no read access. 209.131.76.183 (talk) 19:34, 12 September 2012 (UTC)[reply]

ok i have checked the ftp and all the images folder and all sub folder incl image have read access for owner/group/public, i have unchecked and re checked but still no luck, is there something i have to do like authorize the image or something? it just seems weird that wiki can pull all the details about the image (filesize etc) but wont display the image itself

• on a side note every time i try and upload a new image it puts it in a sub folder of a sub folder (images/9/9e/image . png) is there a way i can set all uploads to a specific folder? this may not solve my original problem but it will make it easier to check file permissions etc. — Preceding unsigned comment added by Nixxy00 (talk • contribs) 09:34, 13 September 2012 (UTC)[reply]

I just realized I missed something before - it looks like you can ftp files to /image, and the wiki uploads them to a subdirectory, where they break. I think the file system permissions are fine - the PHP code for the wiki can open and inspect the files to get the information you mentioned. You probably have an .htaccess file or some other webserver-side access control preventing files from being hosted from subdirectories of the image directory. I bet if you dropped a file in a subdirectory via ftp it would give you the same error. 209.131.76.183 (talk) 14:36, 13 September 2012 (UTC)[reply]

yea it seems to error whatever i do, but i did a test, if i change the permissions on the folder (incl all containing folder) so that they can read/write AND execute on the owner, group and public level i can access the image on wiki, this is even more strange considering you cant execute an image so i have no idea why this should make a difference, but maybe i'll have a look into server settings see if its something on that side affecting it like u say (htaccess file or something) thanks again for your help :D Nixxy00 (talk) 08:04, 14 September 2012 (UTC)[reply]

That actually makes sense - here is the relevant article explaining what execute permission does for a directory:

Filesystem permissions#permissions. I'm not sure why your wiki software created the directory with the wrong permissions, but it sounds like you're on the road to getting things going. 209.131.76.183 (talk) 12:31, 14 September 2012 (UTC)[reply

]