file:// directory listing doesn't reflect reality

VERIFIED FIXED in M14

Status

()

Core
XPCOM
P1
normal
VERIFIED FIXED
18 years ago
18 years ago

People

(Reporter: dbaron, Assigned: Chris Waterson)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [PDT+])

Attachments

(6 attachments)

(Reporter)

Description

18 years ago
DESCRIPTION:  The file:/// directory listings don't reflect reality.  Without
rhyme or reason, some files show up and others don't.  The listing seems to bear
significant resemblence to the state of the directory a month or two ago.

STEPS TO REPRODUCE:
 * load a file:///something/on/your/drive/ in apprunner

ACTUAL RESULTS:
 * many files not listed

EXPECTED RESULTS:
 * all files listed

DOES NOT WORK CORRECTLY ON:
 * Linux, apprunner, 1999-10-29-10-M11 and many prior

ADDITIONAL INFORMATION:
Two attachments to be attached:
 * a screenshot of apprunner
 * an "ls -l" of the directory it's showing
(Reporter)

Comment 1

18 years ago
Created attachment 2488 [details]
screenshot of directory listing
(Reporter)

Comment 2

18 years ago
Created attachment 2489 [details]
the real directory listing
(Assignee)

Updated

18 years ago
Status: NEW → ASSIGNED
Summary: file:// directory listing doesn't reflect reality → [DOGFOOD] file:// directory listing doesn't reflect reality
Target Milestone: M12

Updated

18 years ago
Whiteboard: [PDT-]

Comment 3

18 years ago
Directory listing is not for dogfood.  Putting on PDT- radar.

Comment 4

18 years ago
I just ran into this problem and I came across this bug report.
I am also going to attach a screen shot I got from todays
mozilla build (Sun Nov 14) and compare it to the output of
ls in the same directory.

Could someone point me to the code that is responsible
for this uglyness. I might be able to figure out what
the problem is, but I have no idea where to begin looking.

Comment 5

18 years ago
Created attachment 2868 [details]
The directory contents displayed by mozilla

Comment 6

18 years ago
Created attachment 2869 [details]
The output of ls in the directory.
(Reporter)

Comment 7

18 years ago
One place to start looking might be:

http://lxr.mozilla.org/seamonkey/source/netwerk/protocol/file/src/nsFileChannel.cpp
(Reporter)

Comment 8

18 years ago
cc:ing dejong@cs.umn.edu .  See my previous comment...
(Reporter)

Comment 9

18 years ago
Or maybe...
http://lxr.mozilla.org/seamonkey/source/netwerk/base/src/nsDirectoryIndexStream.cpp

... but the core of this thing has got to be elsewhere still...
(Reporter)

Comment 10

18 years ago
Aha.  Here's a good place to poke around:

http://lxr.mozilla.org/seamonkey/search?string=http-index-format
(Reporter)

Comment 11

18 years ago
This bug seems to have been fixed recently.

(Since it was platform specific (right?), I would guess it was nsFileSpec or
something...)
(Assignee)

Updated

18 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
(Assignee)

Comment 12

18 years ago
I checked in a fix for 16797; it could be that this was a dup of that bug. Or,
as you note, it could be some nsFileSpec voodoo. I'll mark it fixed, we can
re-open, etc. if it resurfaces.
(Reporter)

Updated

18 years ago
Status: RESOLVED → REOPENED
(Reporter)

Comment 13

18 years ago
This bug has resurfaced in Linux mozilla 1999-11-28-08-M12.  The current
symptoms are indistinguishable from those in the original bug report.

Reopening.
(Assignee)

Updated

18 years ago
Status: REOPENED → ASSIGNED

Updated

18 years ago
QA Contact: don → paulmac
Resolution: FIXED → ---

Comment 14

18 years ago
Clearing FIXED resolution due to reopen.

Updated

18 years ago
OS: Linux → All
Hardware: PC → All

Comment 15

18 years ago
This is also present in M11 on Solaris 2.6, and in a different variation under
M11 on NT.

On WinNT4 sp5 (Build ID: 199911520) opening a directory listing via
file:///C|/
fails to list any files or directories at all.
The header (Name Size Last Modified) is there, but there are no contents.

Updated

18 years ago
QA Contact: paulmac → tever
(Assignee)

Updated

18 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago18 years ago
Resolution: --- → WORKSFORME
(Assignee)

Comment 16

18 years ago
This works for me in the build I just pulled. 11/30/1999.
(Reporter)

Updated

18 years ago
Status: RESOLVED → REOPENED
(Reporter)

Comment 17

18 years ago
I'm still seeing this in Linux mozilla 1999-12-01-13-M12.  Reopening.
(Assignee)

Comment 18

18 years ago
Hmm. I'm still not able to reproduce this :-/. Is it deterministic? I.e., If
you press "reload", do the same files show up missing? I'm wondering if maybe
the buffer quantization of the HTTP/Index stream is causing this...
(Reporter)

Comment 19

18 years ago
The output seems the same every time.  However, if I modify the file list in the
directory, the same NUMBER of files seem to be listed all the time.  This number
does vary a little.  In the directory I counted, it was 29.  In another, I think
it was slightly higher (but the browser crashed when i tried to scroll).

Could this have to do with packets of the http-index format?

Comment 20

18 years ago
Clearing WORKSFORME resolution due to reopen.

Updated

18 years ago
Resolution: WORKSFORME → ---

Comment 21

18 years ago
this is a tree filling issue. cc'ing hyatt.
(Assignee)

Comment 22

18 years ago
I don't think it's a bug with the tree code. I think it's either in the
generation of the HTTP/Index stream, or the datasource that converts the
HTTP/Index stream into a graph....
(Assignee)

Updated

18 years ago
Target Milestone: M12 → M13
(Assignee)

Updated

18 years ago
Status: REOPENED → ASSIGNED
(Assignee)

Comment 23

18 years ago
*** Bug 19225 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 24

18 years ago
*** Bug 22592 has been marked as a duplicate of this bug. ***
(Assignee)

Updated

18 years ago
Priority: P3 → P1
Target Milestone: M13 → M14
(Assignee)

Comment 25

18 years ago
Not an M13 stopper. Moving to M14; with luck, may fix it in time for the M13
train.

Comment 26

18 years ago
*** Bug 25721 has been marked as a duplicate of this bug. ***

Comment 27

18 years ago
Does this bug also apply to when Mozilla doesn't show a listing at all? 
Pressing the reload goes on to show a listing though....

I also have a suggestion: could this bug's summary be changed from file:// to 
file:/// because this would come in a search for file:// too.
(Reporter)

Comment 28

18 years ago
I received the following email message from Morten Welinder <terra@diku.dk>. 
Note that "ls -f" will also list files unsorted.  However, now I'm seeing
nothing at all, so I can't verify that it's truncation...

----

I see the same thing.

The file list appears to be truncated.  Yes, truncated, but you wouldn't
know unless you used dirty tricks like

  perl -e 'opendir (DIR,".netscape"); print join (":", readdir (DIR)), "\n";'

to print the directory contents.  "ls" sorts, so it is hard to tell the
order.

Could you please verify that you are seeing truncation too?  (Note, that
"the state of the directory a month or two ago" will include a lot of
files in the true beginning of the directory.)
(Assignee)

Comment 29

18 years ago
from private email. nsIFile guys, does this look like it may cause trouble?

Subject: Mozilla 17586
   Date: Sun, 30 Jan 2000 01:49:23 +0100 (MET)
   From: Morten Welinder <terra@diku.dk>
     To: waterson@netscape.com

I am seeing http://bugzilla.mozilla.org/show_bug.cgi?id=17586 every
single time I go to my ~/.netscape/ directory which contains the
following files:

welinder@anemone:~ > perl -e 'opendir (DIR,".netscape"); print join (":", 
readdir (DIR)), "\n";'
.:..:lock:cert5.db:key.db:history.db:plugin-list:summary2.dat:cache:cookies:pab.
na2:bookmarks.html:plugin-list.BAK:registry:cert7.db:key3.db:secmodule.db:abook.
nab:preferences.js:archive:xover-cache:main.html:history.list:custom.dic:history
.dat:liprefs.js

The files "abook.nab", "archieve", "custom.dic", "history.list", "liprefs.js",
"main.html", "preferences.js", "history.dat", and "xover-cache" do not
show up.

NOTE: that's clearly not random!  It's the tail of the list, but a normal
"ls" will not show that.  I am using M13 (Linux, SuSE 6.3).  Similar
things seen earlier on Solaris 2.7 with M12.

Wild guess: nsDirectoryIterator doesn't have a copy constructor or an
assignment operator.  The defaults just will not work on Unix, so it
should have one.  (In particular, if closedir was hit because of a copy,
that would truncate the list rather effectively.)

Also, the ++ operator on Unix assumes that it will never see ".." and
"." in that order.  Is that safe?

Morten

(Assignee)

Comment 30

18 years ago
sitsofe: see bug 25303
(Reporter)

Comment 31

18 years ago
I confirm I am seeing truncation.  The listing shown in mozilla perfectly
matches "ls -f | head -30 | sort".
(Assignee)

Comment 32

18 years ago
although this was PDT- for DOGFOOD, re-nominating as potential Beta1.
Keywords: beta1
Whiteboard: [PDT-]

Comment 33

18 years ago
Moving [DOGFOOD] to keyword field as dogfood.
Keywords: dogfood
Summary: [DOGFOOD] file:// directory listing doesn't reflect reality → file:// directory listing doesn't reflect reality

Comment 34

18 years ago
Putting on PDT+ radar.  Actually, yes needed for dev dogfood.
Keywords: beta1
Whiteboard: [PDT+]
(Assignee)

Comment 35

18 years ago
Created attachment 5024 [details] [diff] [review]
partial (?) fix
(Assignee)

Comment 36

18 years ago
The above patch fixes bustage that occurred when nsIFile landed. I was relying
on the "length" of a directory being zero (bogus). When nsIFile landed, Unix
actually started coughing up the inode size for directories. The fix is to
explicitly set the stream length to -1 if we're looking at a dir. (Also added a
bunch of debugging code.)

Comment 37

18 years ago
patch looks good to me.
Component: XPApps → XPCOM
(Assignee)

Comment 38

18 years ago
Created attachment 5032 [details] [diff] [review]
changes to nsDirectoryViewer.cpp
(Assignee)

Comment 39

18 years ago
Between nsIFile and this cleanup, I'm not able to reproduce the "spotty
directory" problems. Marking as fixed. N.B. that bug 25303 is still open though!
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago18 years ago
Resolution: --- → FIXED

Comment 40

18 years ago
ouch. I'm seeing this on winnt this morning. Steps to repro. create a new dir in 
c:\ , then view file://c:\ that new dir doesn't appear. Note that I added a 
single char dir "b" and taht one showed up :-/

Reopening.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

Comment 41

18 years ago
I dont see this bug on linux 2/13 (sunday) 11am build.

I created new directories and new files and all of them showed up. I had to give
it a resize to have it show anything though :-( i think that is a separate bug.

Can someone check this on windows too. 2/9 was just about when we went into
regression hell. So I am optimistic this is actually fixed.
(Reporter)

Comment 42

18 years ago
Is that "separate bug" filed?  (That is, the bug that the file directory listing
requires a reflow before it shows up.)  I'd say it's a beta blocker...

Comment 43

18 years ago
yes, either waterson or hyatt has it.
(Reporter)

Comment 44

18 years ago
For the record, it's bug 25303.
(Assignee)

Comment 45

18 years ago
Just so I'm clear, this bug now means:

"When I type 'file://c:\' into the URL bar, nothing shows up. Even after I 
resize the window. But other URLs are ok."

If so, could we please close this and open another bug (assigned to gagan for 
URL parsing)? (Don't mean to be bureaucratic, but this bug kinda meant 
something else...)
(Assignee)

Comment 46

18 years ago
ok, this bug is fixed. Opened bug 27764 to track problems with root directories 
on Win32.
Status: REOPENED → RESOLVED
Last Resolved: 18 years ago18 years ago
Resolution: --- → FIXED

Comment 47

18 years ago
verified:
NT 2000021708
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.