how to update a symlink?

[dank]

I haven't found any answers to updating a symlink here or on Google or searching apache.org...

Say I've got a symlink in the SSL folder, mapping to the non-secure 'nav folder, set up like:

cd /big/dom/xdomain/www/Secure_Server/
ln -s /big/dom/xdomain/www/nav/ nav

Now, when I update a file in /www/nav/ and look at the corresponding file in /www/Secure_Server/nav/, it shows the updated file's contents but the include on the server is still pulling from the old contents. :hrmm:

Does the symlink have to be removed and recreated each time? I would hope not, or that eliminiates half of the reason for using it in the first place -- not having to update two identical files in two places (the other being to avoid secure/non-secure content warnings if using a shared file).

I read that not using the '-s' switch would make it a hard link and point to the data not the file. Is that perhaps part of the answer?

Dan

[Kevin]

The symlink does not need to be recreated each time. You are probably just getting a cached copy of the data.

A hard link would work the same as a symlink except that they are a bit harder to manage.

[dank]

You are probably just getting a cached copy of the data.
Is there any way of working around that? The file date doesn't get updated on the symlink copy, which presumably is the source of the problem. I guess other people might be seeing the proper content, but it's tough to troubleshoot when I can't...

Dan

[Kevin]

Do you get the updated content if you hold shift and hit reload?

How about if you restart the browser?

[dank]

No and no. Even loading a different browser still shows the old content.

(I never got the notification of your reply and didn't check back in until just now.)

Dan

[Rich]

Now, when I update a file in /www/nav/ and look at the corresponding file in /www/Secure_Server/nav/, it shows the updated file's contents but the include on the server is still pulling from the old contents.
Dan, if you use your browser to view
https://secure.domain.com/whatever
-and then-
http://www.domain.com/Secure_Server/whatever
Do you see the 'old' or 'new' content?

[dank]

I hadn't thought to try that, but it still shows the old content.

Oddly, when I look at the symlink'd copies of the files (via FTP and the CNC File Manager), their date now shows 8/23, whereas previously when I looked at it in FTP after updating the original file, the symlink file dates didn't change. It doesn't seem to be affecting the displayed content, though... Is there some sort of trickle down waiting period? First the server updates the dates, then it updates the delivered content? I can't imagine how that process would actually operate, since it's somehow delivering content that no longer exists according to the files on the server...

Dan

[Kevin]

When you get this old data in your browser does the log file on the server register the hit? If you are pulling data from a cache somewhere (like your ISP) then it will either not show the hit or it will be a HEAD instead of a GET.

[dank]

Oddly, none of the pertinent include files are being logged, original or copy. That's a new one... I could've sworn I've always seen *.php include files show up in the logs.

Dan

[kitchin]

An include()'d or require()'d file would not show up in the Apache logs.
Could PHP be doing some sort of evil caching? Just asking.

[dank]

An include()'d or require()'d file would not show up in the Apache logs.
Looking at the stats, it would appear you're right. I thought I remembered them showing up in the past...

Could PHP be doing some sort of evil caching?
That seems as good a guess as any, but why would a symlink'd file change things? Wouldn't Apache be handling that prior to anything PHP sees?

Dan

[kitchin]

Oh, re: apache logs
require('http://.../file.php') will appear, but require('file.php') will not.
AFAIK.

[dank]

Any more thoughts from the FQ side of the fence? Am I misunderstanding how this should work, or is there some sort of glitch in the server's handling of SSL symlinks?

Dan

[Bruce]

Any more thoughts from the FQ side of the fence? Am I misunderstanding how this should work, or is there some sort of glitch in the server's handling of SSL symlinks?A symlink (aka soft link, symbolic link, or named link) work at the kernel level. As such, there is no such thing as a "SSL symlink". At the instant they are created, all normal open function calls automatically operate on the file the link references. There is no caching of any kind that would lose coherence as you describe.

As far as applications go, there are three possibilities for what they will see:
1) The link references an existant file and the applications use standard open/stat system calls -- it just works, always.
2) The link references an existant file but the application checks for symlinks -- it either always works or always doesn't work, depending on if they allow symlinks.
3) The link does not reference an existant file -- it always does not work.
"Works" above means opens the current content of the referred-to file.

Case #1 above is the normal case for the vast majority of files. The most common exception is archivers like tar. Apache falls into case #2, but it only uses the symlink check to determine permissions on an URL, and our servers allow symlinks (you would know the first time you tried if they did not). If you see any data at all, you are not working with case #3.

I hope this satisfactorily answers your question.

[dank]

All that's good and well, but it doesn't seem to explain the behavior I'm seeing. Have/Can you run a test to see if a symlink in the Secure_Server folder updates properly? As far as I can tell, it doesn't.

It's on foodandhealth.com, referencing the navfiles folder, if you'd rather just check that.

Dan

[Terra]

There is no caching of symlinks, when they are changed, the Linux filesystem layer will do the right thing (always)... There is no 'update' per se, the filesystem sees it immediately upon next read of that symlink...

To the best of my knowledge, Apache does not cache symlinks either, however PHP might...

However, I cannot speak for what browsers (caching) may do with things that are symlinked...

--
Terra
--you will have to trust us on this one as we have a pretty deep understanding of how the Linux Filesystem layer works--
FutureQuest

[Terra]

Out of curiosity, would you be interested in having your SSL re-rooted to the 'www' directory?

This may dispense with the need for symlinks...

--
Terra
--wishes hardlinks could cross file system boundaries--
FutureQuest

[Don]

It's on foodandhealth.com, referencing the navfiles folder, if you'd rather just check that.Your original post referenced a nav folder, not a navfiles folder. Is that a typo, or do you have two different folders?

--
Don

[DogAndPony]

A symlink (aka soft link, symbolic link, or named link) work at the kernel level. As such, there is no such thing as a "SSL symlink". At the instant they are created, all normal open function calls automatically operate on the file the link references. There is no caching of any kind that would lose coherence as you describe. [...]And with this excellent explanation, Bruce once again earns the "Most Appropriate Avatar" Award. :yeah:

Greatest support anywhere!

[dank]

Your original post referenced a nav folder, not a navfiles folder. Is that a typo, or do you have two different folders?
No, I just wrote it shorthand originally, as the specific folder didn't seem of any importance with the domain name not specified.

you will have to trust us on this one as we have a pretty deep understanding of how the Linux Filesystem
I'd be a lot more trusting if you would run a test confirming or denying what I'm seeing... I have no way to explain it other than the server not doing what it's supposed to, unless I've overlooked something worthy of a forehead slap. But since no one has yet highlighted what that might be, what other conclusion can or should I come to?

would you be interested in having your SSL re-rooted to the 'www' directory?
I'm not 100% sure what that means to re-root it. Can you elaborate on that a bit? Any drawbacks?

Dan

[Don]

But since no one has yet highlighted what that might be, what other conclusion can or should I come to?Well, I do see a different left menu bar for cart.php. Before you migrated to the symlink solution, did the include in cart.php point to a different file than the one used in index2.php and the like? Could it still be pointing there? Because if it isn't, I think we need to start considering supernatural explanations.

--
Don

[dank]

Problem solved, thanks for pointing my forehead in the direction of the brick wall. :blush: My apologies to FQ; nothing wrong with the server.

Dan