inconsistent symbolic links

I have a directory with several thousand avatars. I want this one directory to be shared amongst various apps. When we create a symbolic link with "ln -s" the permissions show "lrwxrwxrwx'.

I'm not sure what the pattern is but in some places these links work fine. I can cd to the path, look at files, touch foo and rm foo, then cd .. back to the directory that has the link. And with FileZilla I can click on the link and the pointer jumps to the actual directory in the file tree. For other links FileZilla says it failed to obtain a directory listing and write operations from PHP fail.

To avoid the problem for now I've had to remove a couple of the links create the directory, then copy a mass of images to the local directory to be accessed by a single app. This is a waste of space and will cause management issues later.

Can anyone suggest why a link from X1 to Y works but a link from X2 to Y does not? That's for both read/write access.

Thanks!

Are all links fully contained within one user's home directory?

Are you using SFTP with FileZilla?

Have you logged in via shell and tested the 'cd' command to follow these links?

My concerns are mostly due to ownership, but there may also be something weird with the setup.

-Scott

Thanks for the response, bud.

I spent some intense time with this to answer your (simple but better double-check) questions and I found FileZilla has an aggressive cache that doesn't clear unless you visit another site, then come back, then refresh! Logging off/on then doing a refresh doesn't clear it. I'm still running a v3.0 release and I'll upgrade to the current v3.1.5, and report the issue to them if this persists.

Bottom line is that ln -s works as one one hope, problem solved.

Thanks much!

In reply to:

---

2008-10-22 - FileZilla Client 3.1.5 released
New features:
Handle symbolic links on servers. If trying to access a symbolic link, FileZilla will first try to CWD into it, and if that fails, will treat it as a file instead. During recursive operations, any directory link encountered will not be followed, but file links will be downloaded.

---

Just in time eh?

Yer on the ball, dude. Yeah, I see that. Amazing how timing works like that, eh?

However, it looks like they still don't have this quite right. I filed an issue against 3.1.5. This point bothers me: "will first try to CWD into it, and if that fails, will treat it as a file instead". IThe CWD should only fail if the link is to a file rather than to a dir, but in my case it is a dir, so it shouldn't fail, and since it is, other issues follow. I'll post here with a recap when this gets resolved.

Thanks again.

If you're on Windoze check out WinSCP

Free, of course.