Closed
Bug 53731
Opened 24 years ago
Closed 24 years ago
No directory symbolic links in file picker
Categories
(SeaMonkey :: UI Design, defect, P3)
Tracking
(Not tracked)
VERIFIED
FIXED
Future
People
(Reporter: hymie, Assigned: bryner)
References
Details
(Keywords: helpwanted)
When downloading a file, the filebox which allows you to choose a directory doesn't display symbolic links which point to directories.
Comment 1•24 years ago
|
||
Hyman Rosen could you please explain this in more detail. Also what build were you testing.
Reporter | ||
Comment 2•24 years ago
|
||
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.
Comment 3•24 years ago
|
||
filepicker bug?
Comment 4•24 years ago
|
||
Pav, is this yours?
Assignee: asa → pavlov
Status: UNCONFIRMED → NEW
Component: Browser-General → XP Apps
Ever confirmed: true
Comment 6•24 years ago
|
||
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
Comment 8•24 years ago
|
||
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.
Reporter | ||
Comment 9•24 years ago
|
||
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.
Comment 10•24 years ago
|
||
NFS should be transparent as far as file type (mode) goes. Is there perhaps an automounter doing something here? /be
Reporter | ||
Comment 11•24 years ago
|
||
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.
Comment 13•24 years ago
|
||
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?
Reporter | ||
Comment 14•24 years ago
|
||
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.
Comment 15•24 years ago
|
||
*** Bug 55333 has been marked as a duplicate of this bug. ***
Comment 16•24 years ago
|
||
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.
Reporter | ||
Comment 17•24 years ago
|
||
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.
Comment 18•24 years ago
|
||
Yes, that is a grave bug which certainly needs to be fixed.
Assignee | ||
Comment 19•24 years ago
|
||
Is this fixed now that we have a workaround for the dangling symlinks problem?
Comment 20•24 years ago
|
||
It should be. Hyman, do you still see this in recent trunk builds?
Assignee | ||
Comment 21•24 years ago
|
||
No response from bug reporter + I can't reproduce this = Fixed
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Updated•20 years ago
|
Product: Core → Mozilla Application Suite
You need to log in
before you can comment on or make changes to this bug.
Description
•