Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix(core): Check existence of cache symlink without usage of readlink() #10633

Merged
merged 1 commit into from
Nov 30, 2016

Conversation

iionly
Copy link
Contributor

@iionly iionly commented Nov 27, 2016

This is a backport from the 2.3 branch.

It's not only a matter of readlink() not being necessary. At least on my server the readlink() call produces an "Invalid argument" warning resulting in the check for existence of the cache symlink to fail even if the symlink is correctly set up.

@hypeJunction
Copy link
Contributor

Should we perhaps try both? Without readlink() first and then with readlink()? I think this will vary server to server, better cover our bases.

@iionly
Copy link
Contributor Author

iionly commented Nov 29, 2016

@hypeJunction is the readlink() call necessary? I only backported 4ca717d which is already in 2.3 and master branch which already removed the readlink() call.

I also found out what causes readlink() to fail now. readlink() (and also for example is_link()) fails to work due to the / at the end of the $link string. So, if readlink() should get added again this / must be removed both from the $link and $target string for it to work.

@hypeJunction
Copy link
Contributor

That's odd that your file system can't tell /cache/ from /cache. Everything works fine on my end, so I am against any changes until there is a scientific explanation.

@iionly
Copy link
Contributor Author

iionly commented Nov 29, 2016

Does it NOT work for you without the slash at the end?

My guess is that the exact functionality of readlink might depend on the OS used. What OS are you testing it on and what version of php? In my case it's Linux on php 5.6.

The readlink docs on php.net is of no help. But a comment posted on is_link() (at http://php.net/manual/en/function.is-link.php#72038) gives some indication that a similar issue occurs also with is_link() - where the parameter must be a filename. In case of is_link() it works in case the target of the link is a directory only without the trailing slash for this guy - and me.

Again, my guess: it works not much different for readlink as it works for is_link(), i.e. only without the trailing slash.

Is a trailing slash at the end of a full path of a filename (here linkname) even logical? If you give the full path to a directory it seems not to matter much. But in case of a filename the trailing slash seems wrong to me (or would you add a trailing slash when including a php file at the end of its name?).

Maybe you are just lucky it works for you with the trailing slash. I can only say it doesn't work for me - without any scientific explanation - and Google was also not helpful in finding an explanation.

Regardless, the current code in the 2.2 branch is already different from the code in 2.3 and master. So what now to get consistent in code at least? Backport the code from 2.3 (which would solve the problem also for me) or add readlink() again in 2.3 and master - resulting it not working anymore at least for me...

@hypeJunction
Copy link
Contributor

Let's start by adding a test. If it fails on Travis which runs linux, we can take it from there and see where out logic is flawed

@hypeJunction
Copy link
Contributor

Trying to add some tests here: #10637

@hypeJunction
Copy link
Contributor

Looking at the code now. We have already made that change in 2.3, so we can merge this as a bug fix. I will work on some tests for 2.3.

@hypeJunction hypeJunction merged commit d916693 into Elgg:2.2 Nov 30, 2016
@hypeJunction
Copy link
Contributor

In the future, please avoid using core as a commit component name. Everything is a core here. fix(cache) would have been more appropriate.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants