118651 - nsIFileURL.file needs to return nsIFile that was set

Status: RESOLVED FIXED

(Core :: Networking, defect, P2)

Description

[Kathleen :Brade]

For publishing, I'd like 1 API that takes the destination location.  I'd like to
use nsIURI as the type.  However, I need that to work on a Mac for saving (which
needs nsIFile) so I'd like to be able to QI or get the nsIFile that may have
been set.

Currently nsIFileURL::file doesn't return the nsIFile that was set (but rebuilds
it from the pieces or from the string).  

note to self and Adam:  I expect callers to use nsIIOService::newFileURI to set
the file if it's a local file such as a file chosen by a file picker 
(http://lxr.mozilla.org/seamonkey/source/netwerk/base/src/nsIOService.cpp#752)

Comment 1

[Kathleen :Brade]

As part of this work (or part of a new bug?), it'd be nice to have "synchronize"
so if someone tweaks the nsIFile (such as adding a file extension), it'd be nice
if the companion nsIFileURL/nsIURL would be updated to reflect the new name/path.

It's possible to work around this but it'd be cleaner to have a method to call
and do it for us.

Comment 2

[Adam Lock]

The checkin for bug 110135 has potentially lossy due to the URI not pointing to
the same place the associated file does.

For example, if I have a file "c:\foo" associated with a URI of "file://c|foo"
and I append ".htm" to the filename, the file is now "c:\foo.htm" but the URI is
still "file://c|foo". There needs to be some kind of synchronisation mechanism
where the URI can resync with the latest version of the file.

Comment 3

[Darin Fisher]

in that case you need to manually call SetFile on the URL object.  that is the
only form of synchronization we currently support, and i think it should be
sufficient unless you don't own the URL anymore.

Comment 4

[Adam Lock]

That sounds like what I'm after. I'll try it out and report back.

Comment 5

[Adam Lock]

This appears to work correctly. Kathy was there something else you wanted to
keep this bug open for or can we close it - SetFile resyncs the URI to the file

Comment 6

[Kathleen :Brade]

When I last checked, getting the file was not doing the right thing (the nsIFile
set wasn't duplicated or stored); instead it was regenerating the nsIFile from
string pieces which is lossy on Mac.

This is still a valid issue that is very important to fix.

Darin--can you fix this for 0.9.9 milestone?

Comment 7

[Darin Fisher]

-> 0.9.9

Comment 8

[Darin Fisher]

Attachment: v1.0 patch

this patch makes nsIOService::NewFileURI invoke NewFileURI on
nsFileProtocolHandler, which in term constructs an empty nsStandardURL and
calls SetFile on it instead of Init with a file path.  As a result,
nsStandardURL::GetFile will return a nsIFile::Clone'd copy of the original
nsIFile passed to NewFileURI, which I believe should be sufficient to solve
this bug.

it was necessary to also make nsStandardURL::SetFile switch to the no-auth URL
parser, since the std-url parser is the default.  this shouldn't really have
much effect in this case, but it is done for correctness.

Comment 9

[Doug Turner (:dougt)]

Comment on attachment 67023 [details] [diff] [review]
v1.0 patch

looks fine.  hide the mac nightmare in the nsIFile.

Comment 10

[rpotts (gone)]

Comment on attachment 67023 [details] [diff] [review]
v1.0 patch

sr=[e-mail]

Comment 11

[Darin Fisher]

fixed-on-trunk