Open Bug 270521 Opened 20 years ago Updated 10 months ago

file:///a:/ does not work unless floppy has data on it

Categories

(Core :: Networking: File, defect, P5)

x86
Windows XP
defect

Tracking

()

People

(Reporter: tonglebeak, Unassigned)

References

()

Details

(Keywords: dupeme, Whiteboard: [necko-would-take])

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041114 Firefox/1.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041114 Firefox/1.0

My floppy drive is a:

file:///a:/ will not work at all unless there is some data on the disk. While
this isn't a really big deal, Firefox should still list the contents of the disk
(which is blank, but meh).

Reproducible: Always
Steps to Reproduce:
1.Insert an empty floppy disk into your floppy drive (or format if required)
2.Go to file:///[your floppy drive here] ex: file:///a:/
3.

Actual Results:  
Nothing worked.

Expected Results:  
Displayed "Index of A:/"
Whiteboard: dupeme
Whiteboard: dupeme → DUPEME
Same for Seamonkey.
Assignee: bugs → darin
Component: File Handling → Networking: File
Product: Firefox → Browser
QA Contact: bmo → benc
Version: unspecified → Trunk
A warning is displayed when there is no disk in the drive, saying there is no
disk in the drive (not sure if this was the case before), but the index still
doesn't show up for a blank one >_>
blank or unformated?
Unformatted or no disk shows an alert saying to insert a disk, blank disk gives
nothing.
This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/
Still reproducable in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b5)
Gecko/20050925 Firefox/1.4 ID:2005092506
Status: UNCONFIRMED → NEW
Ever confirmed: true
-> default owner
Assignee: darin → nobody
QA Contact: benc → networking.file
Can confirm on the linux side now. Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9) Gecko/2008062219 (Gentoo) Firefox/3.0

/dev/fd0 points to /mnt/floppy. WHen pulling up /mnt everything's listed. If I pull up /mnt/cdrom w/ no cd in, the directory is still listed (with .keep). If I try to pull up /mnt/floppy, nothing at all happens. No listing, no nothing. ls -la /mnt/floppy shows it has a .keep file as well. Changing to Os->All as this isn't windows only (minor though).
OS: Windows XP → All
Aaron:

Please file a new bug.

The way floppy drives works varies by OS, but from Necko's perspective (or probably NSPR, actually), it shouldn't be the same. If this is broken in linux, even if it is the same behavior, it is probably a different problem.

os -> xp.
OS: All → Windows XP
Whiteboard: DUPEME → DUPEME [necko-would-take] [good first bug]
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: -- → P5
Whiteboard: DUPEME [necko-would-take] [good first bug] → [necko-would-take]
Severity: minor → S4
Keywords: good-first-bug
You need to log in before you can comment on or make changes to this bug.