No directory symbolic links in file picker

VERIFIED FIXED in Future

Status

P3
normal
VERIFIED FIXED
19 years ago
11 years ago

People

(Reporter: hymie, Assigned: bryner)

Tracking

({helpwanted})

Trunk
Future
x86
Linux
helpwanted

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

19 years ago
When downloading a file, the filebox which allows you to choose a directory
doesn't display symbolic links which point to directories.

Comment 1

19 years ago
Hyman Rosen could you please explain this in more detail.  Also what build were
you testing.
(Reporter)

Comment 2

19 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.
filepicker bug?

Comment 4

19 years ago
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
(Assignee)

Comment 7

19 years ago
accepting
Status: NEW → ASSIGNED

Comment 8

19 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

19 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.
NFS should be transparent as far as file type (mode) goes.  Is there perhaps an
automounter doing something here?

/be
(Reporter)

Comment 11

19 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 12

19 years ago
->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?
(Reporter)

Comment 14

19 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.
*** 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.
(Reporter)

Comment 17

18 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.
Yes, that is a grave bug which certainly needs to be fixed.
(Assignee)

Comment 19

18 years ago
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?
(Assignee)

Comment 21

18 years ago
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
Product: Core → Mozilla Application Suite

Updated

11 years ago
Component: XP Apps: GUI Features → UI Design
You need to log in before you can comment on or make changes to this bug.