When downloading a file, the filebox which allows you to choose a directory doesn't display symbolic links which point to directories.
Hyman Rosen could you please explain this in more detail. Also what build were you testing.
This was in build 2000091312. I go to download a file from some web site. I am presented with the save file dialog, and I use the .. button to go up to the root directory, in order to try to then select my home directory. On my system, I refer to my home directory as /u/home/hymie, but the "hymie" entry in /u/home is not really a directory. Instead, it's a symbolic link to my real home directory, which is /disk/devhome/hymie. When I change directory to /u/home in the save file dialog, the list of subdirectories in the left list box does *not* include "hymie", presumably because the code sees that entry as a symbolic link file and excludes it, without realizing that it does in fact *point* to a directory.
Pav, is this yours?
Assignee: asa → pavlov
Status: UNCONFIRMED → NEW
Component: Browser-General → XP Apps
Ever confirmed: true
QA Contact: doronr → sairuh
methinks bryner now owns the unix file picker
Assignee: pavlov → bryner
Component: XP Apps → XP Apps: GUI Features
Summary: No directory symbolic links in filebox → No directory symbolic links in file picker
Status: NEW → ASSIGNED
Hmmm, strange... I've tested this, and I see symlinks to directories just fine, namely as if they were the directory. Can you try a test for me? Go to /tmp or someplace simple you have write permissions. Then: echo "a" > a ln a b ln -s a c mkdir d ln -s d e echo "f" > e/f See if the xp filepicker does the Right Thing (in this case, treat the symlinks as if they're the file/directory they reference) for those.
Yes, this works fine. The difference appears to be that in my case, I'm looking at a file system mounted via NFS from a Soalris 5.6 machine. I used the file picker to look at the root of the mounted file system, and none of the directory symbolic links show up.
NFS should be transparent as far as file type (mode) goes. Is there perhaps an automounter doing something here? /be
No automounter; everything is explicitly mounted. Doing ls -l in those directories works fine - I see all the links. But they're not in the filepicker.
Target Milestone: --- → Future
Well, I installed an NFS server (linux, kernel), mounted stuff, made a symlink pointing at the mounted directory, made a symlink pointing at a directory within that mount, made a symlink pointing at a symlink (to a directory) within that mount. So far, everything shows up just fine in the filepicker. Symlinks on nfs mount, symlink to nfs mount, symlink to dir on nfs mount, symlink to symlink (to dir) on nfs mount, all show and get the right icon. Anything else I could try?
The file picker fails to come up at all in today's version (2000100321) so I can't really say. As I said, I'm mounting from a Solaris 5.6, and the directory I'm mounting is itself a symbolic link on the remote system. That is, I am mounting joe:/u on /u, and on joe, /u is itself a symbolic link. I'm going to try mounting joe:/realname directly, and see if that makes a difference, once I get a file picker back.
*** Bug 55333 has been marked as a duplicate of this bug. ***
Useful clue in bug 55333: if we encounter a dangling symlink (ln -s /does/not/exist ./foo), we choke. "We" being the back end, not the filepicker. Could you see (if your filepicker opens again) if you've got a dangling symlink which might explain this problem? Otherwise we'll have to keep looking.
Yes, there are bad symlinks in the directories. They are not under my control to remove, and I would consider it a bug to not display good symlinks just because you've seen a bad one.
Yes, that is a grave bug which certainly needs to be fixed.
Is this fixed now that we have a workaround for the dangling symlinks problem?
It should be. Hyman, do you still see this in recent trunk builds?
No response from bug reporter + I can't reproduce this = Fixed
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
yep, wfm. vrfy.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.