151843 - nsIFile::Append inconsistent across platforms [was: nsiFile append behaviour changed for empty string]

Status: VERIFIED FIXED

(Core :: Networking: HTTP, defect, P4)

Description

[Peter Wilson]

The behaviour of the nsIFile (possibly nsILocalFile) append method has changed
w.r.t. to the empty string.
It used to be possible to do:
Win2000 build: 2002061104

aFile.append("")

This would take a path and ensure that it terminated with the correct directory
separator for the OS. eg File("c:\temp").append("") would yield c:\temp\ on
Windows. Appropriate behaviour on Unix would be to use the "/" character.

This call now throws an exception. This forces the programmer to discover which
OS they are running under and then append the appropriate separator.

Comment 1

[Matthias Versen [:Matti]]

Do you use embedding ?

Comment 2

[Peter Wilson]

Not embedding, just regular Mozilla.

Comment 3

[Matthias Versen [:Matti]]

-> Darin: do you own nsiFile ?

Comment 4

[Darin Fisher]

hmm... why do you need this behavior?  i think the original behavior was an
unintended side-effect, but i could be wrong about that... cc'ing some other
nsIFile folks.

Comment 5

[Peter Wilson]

Don't sweat it - I've already worked around the problem.

Comment 6

[Darin Fisher]

resolving WONTFIX .. unless someone can correct my assumptions about the meaning
of the API.

Comment 7

[Alec Flett]

can we document this somewhere, like in nsIFile.idl, something to the effect of
"unles specified otherwise, null or empty strings are not valid parameters in
this interface, and an exception will be thrown"

Comment 8

[Darin Fisher]

ah, there is a difference between the XP_WIN and XP_UNIX impls.  the XP_UNIX
impl just returns NS_OK on AppendNative(""), whereas the XP_WIN version throws
an exception!  we need to unify these.  i think the XP_UNIX behavior makes the
most sense.

reopening

Comment 9

[Darin Fisher]

Attachment: v1 patch

this patch touches up the impl of AppendNative for XP_WIN, XP_MAC, and XP_OS2. 
with this patch, AppendNative now does an early return of NS_OK if the input is
an empty string.  this seems reasonable, and it shouldn't impact any of the
callers since they would otherwise already have a XP_UNIX bug.

Comment 10

[Doug Turner (:dougt)]

Comment on attachment 97490 [details] [diff] [review]
v1 patch

r=dougt

Comment 11

[Alec Flett]

Comment on attachment 97490 [details] [diff] [review]
v1 patch

sr=alecf

Comment 12

[Darin Fisher]

fixed-on-trunk

Comment 13

[Tom Everingham]

verified - checked with Lxr that patch was applied