Closed Bug 53731 Opened 24 years ago Closed 24 years ago

No directory symbolic links in file picker

Categories

(SeaMonkey :: UI Design, defect, P3)

x86
Linux
defect

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.
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.
filepicker bug?
Pav, is this yours?
Assignee: asa → pavlov
Status: UNCONFIRMED → NEW
Component: Browser-General → XP Apps
Ever confirmed: true
default qa
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
accepting
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.
->future, helpwanted
Keywords: helpwanted
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
Closed: 24 years ago
Resolution: --- → FIXED
yep, wfm. vrfy.
Status: RESOLVED → VERIFIED
Product: Core → Mozilla Application Suite
Component: XP Apps: GUI Features → UI Design
You need to log in before you can comment on or make changes to this bug.