Closed
Bug 29439
Opened 25 years ago
Closed 9 years ago
file: directory listing needs hidden files pref
Categories
(Core :: Networking: File, enhancement)
Core
Networking: File
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: bugzilla, Unassigned)
References
Details
(Keywords: testcase)
If you do local browsing hidden files are not shown. This should not be the case if the user has the "Show all files" option in Explorer to on. The "Show all files" option: Start Windows Explorer View -> Folder Options -> View -> Hidden Files (Show all files) This will set this reg.db setting: [HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced] "Hidden"=dword:00000001 More info: http://msdn.microsoft.com/library/psdk/bestprac/Topics/RULE40.HTM Expected: If the "Show all files" is on Hidden files should be shown!
Updated•25 years ago
|
Target Milestone: M15
Comment 3•24 years ago
|
||
I don't know if this is an issue for Doug Turner or Bill Law.
Assignee: warren → law
Comment 4•24 years ago
|
||
By design? http://lxr.mozilla.org/seamonkey/source/netwerk/base/src/nsDirectoryIndexStream. cpp#183 Robert, what was the reason behind this?
Comment 5•24 years ago
|
||
Reason for the hidden file check: Mac users should never be shown hidden files, otherwise they see lots of special files/folders which they shouldn't. On Windows, you could certainly enhance the code to show hidden files or not based upon the "Show all files" option (if you care to). Similar situation for Unix. (Perhaps check some environment variable? Or pref? Or whatever.) In general, if you don't want to add support for controlling whether to show hidden files or not, I believe its best to opt for not showing them, as most users don't know/care, and they add clutter to file listings.
Updated•24 years ago
|
Target Milestone: M16 → M18
Comment 7•24 years ago
|
||
Maybe the defaults should be different for different platforms. I think unix users want to see .files when they do a listing. At the very least, there should be a pref for this, and probably a checkbox in the prefs ui.
Comment 8•24 years ago
|
||
As mentioned, I think that a pref for this would be great. Who wants to step up for implementing it? [For Mac users, the pref is irrelevant... invisible files/folders should NEVER be shown.] The reason why I believe that we SHOULD NOT show invisible files by default on other platforms is because usually the OS in question doesn't either. To see "invisible" files/folders, you have to specifically state that's what you want. Examples: (Unix) "ls -a" (DOS) "dir /ah" (Windows) You have to enable the "Show Hidden Files" option (buried in the UI) Against, the average user probably doesn't care about invisible files... they were made that way for a reason.
Reporter | ||
Updated•24 years ago
|
Severity: normal → enhancement
Summary: Hidden files should be shown in local browsing if "Show all files" option is on → RFE: Hidden files should be shown in local browsing if "Show all files" option is on
Reporter | ||
Comment 11•23 years ago
|
||
RFE cleanup. RFE is already indicated by the Severity field...Sorry for the spam!
Summary: RFE: Hidden files should be shown in local browsing if "Show all files" option is on → Hidden files should be shown in local browsing if "Show all files" option is on
Comment 12•23 years ago
|
||
clarified summary. testcase: MacOS: probably root level of MacOS still has DesktopDB (hidden file) UNIX: use home directory Windows: I think Rob's comments, generally suggest that this should be a UNIX/Win pref. In MacOS, invisible files are beyond visibility in the Finder.
Keywords: testcase
OS: Windows 98 → All
QA Contact: tever → benc
Hardware: PC → All
Summary: Hidden files should be shown in local browsing if "Show all files" option is on → file: display needs hidden files pref
Comment 14•23 years ago
|
||
+[RFE] - sorry, not everyone has room to display "severity"...
Summary: file: display needs hidden files pref → [RFE] file: display needs hidden files pref
Comment 15•22 years ago
|
||
MacOS X is a bit weird: Unix files are visible, if they are group owned admin, but not wheel. So many of the top level / links appear inside "macintosh hd", but cannot resolve if you click on them. In Terminal.app, the default users are members of both groups "admin" and "wheel". Weird. Need to research more.
Comment 16•22 years ago
|
||
*** Bug 147073 has been marked as a duplicate of this bug. ***
Summary: [RFE] file: display needs hidden files pref → file: display needs hidden files pref
Comment 17•21 years ago
|
||
Updating to Win-only. Mach-O does display hidden files, as does Linux (Mozilla 1.4a)
OS: All → Windows 98
Hardware: All → PC
Summary: file: display needs hidden files pref → file: directory listing needs hidden files pref
Comment 18•20 years ago
|
||
*** Bug 252874 has been marked as a duplicate of this bug. ***
Comment 19•19 years ago
|
||
*** Bug 318891 has been marked as a duplicate of this bug. ***
Comment 20•18 years ago
|
||
(In reply to comment #17) > Updating to Win-only. > Mach-O does display hidden files, as does Linux (Mozilla 1.4a) I disagree making this bug win-only. The request is a preference to display/not display hidden files, which applies to all systems. For example on Linux systems it is annoying that hidden files (ie. the ones starting with a dot) are displayed no matter what. A preference for that would make the directory listing a lot more usable.
Comment 21•18 years ago
|
||
Unfortunately this does not seem to work anymore with Thunderbird 1.5.0.8. I need to attach a file in a hidden subdirectory of my home directory, but not even .<TAB> does will show it. The whole file dialog seems very primitive and with this problem even buggy and should really be replaced with the native file dialog (from kdelibs in my case). Openoffice can do that, so it is possible.
Comment 22•17 years ago
|
||
This bug still exits on WinXP (please adjust OS from its present Win98, as was done for duplicate Bug 252874). It is present in the trunk code that is soon to become Fx3.0, despite other, substantial enhancements in that code for local directory listings. There is a check box in the listings now with the label "Show hidden objects" but it determines whether or not dot files will be hidden, and dot files are not hidden objects on MW Windows. If you enter a file URL for a OS hidden directory, e.g., for the Application Data directory in one's Documents and Settings directory, you do get a listing and can descend its tree to one's Firefox profile, but none of those hidden directories or files are placed in history, and a listing for the Application Data's parent directory still doesn't include it. This bug exists when one has made the OS setting such that "Hidden Folders and Files" should be displayed and My Computer does respect that setting, i.e., includes them in its listings.
Updated•16 years ago
|
Assignee: law → nobody
Status: ASSIGNED → NEW
OS: Windows 98 → All
Priority: P3 → --
QA Contact: benc → networking.file
Hardware: x86 → All
Target Milestone: mozilla1.2alpha → ---
Comment 23•13 years ago
|
||
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13 ( .NET CLR 3.5.30729) Yes.
Comment 24•13 years ago
|
||
Chrome 8, IE8, Opera 11 all display hidden files/folders (on WinXP). Does this warrant some parity flags to the whiteboard?
Comment 25•9 years ago
|
||
This isn't on anyone's work list and realistically is an abandoned idea. I will close as wontfix - if someone has a patch or is actively going to work on it please reopen. (but please, only then.)
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•