47382 - getFolder object created with file:/// unexpectedly omits second parameter

Status: VERIFIED INVALID

(Core Graveyard :: Installer: XPInstall Engine, defect, P3)

Description

[Jimmy Lee]

Build: 2000-08-02-04-M17(MAC)

1. From http://jimbob/trigger3.html, select Acceptance drop-down menu and
   choose a_fileop_filedelete
2. Click Trigger case button
3. Click Install button from confirmation dialog

RESULT:
File is unexpectedly not deleted.  The install.log reveals that path to target 
file was not known.  This works fine on both Windows and Linux.  This type of 
failure blocks most file operations tests if not all on Macintosh.

EXPECTED RESULT:
File is deleted.  Install.log shows full path to specified file.

Install.log:
-------------------------------------------------------------------------------
http://jimbob/jars/a_fileop_filedelete.xpi  --  08/02/2000 15:10:03
-------------------------------------------------------------------------------

     Acceptance: a_fileop_filedelete
     -------------------------------

     ** addFile returns = 0
     [1/1]	Installing: jimmymac:Projects:moz0802:Netscape 
Folder:filedelete.txt

     Install completed successfully
     The File Delete part
     --------------------

     ** The file pathway = jimmymac:Projects:moz0802:Netscape Folder:
     ** ERROR (-216): Deleting file: jimmymac:Projects:moz0802:Netscape Folder
     ** fileDelete returns = -216

     Install cancelled by script
     Finished Installation  08/02/2000 15:10:03

Install script:
////////////////////////////////////////////////////////////////////////////////
// a_fileop_filedelete.js
// 
// Acceptance test
// 	 Checks the ability to delete a known file from a known directory
// 	 A file, smrtupdt.txt, is installed as filedelete.txt under the "Chrome" 
//       directory filedelete.txt should be removed after fileDelete is called
//       (temporarily installing the file "filedelete.txt" into "Program" //       
folder)
//
// ~ XPInstall QA
//   November 29, 1999
//   February 25, 2000. Updated. Now uses File object and renamed API.
//   April 17, 2000. Changed File.delete to File.remove.
//
////////////////////////////////////////////////////////////////////////////////

var jarSrc = "filedelete.txt";

initInstall("Acceptance: a_fileop_filedelete", "acceptance", "1.1.1.1", 0);
g = getFolder("Program");
err1 = addFile("fileop_filedelete", jarSrc, g, jarSrc);
logComment("addFile returns = " + err1);
doItOrDie();

initInstall("The File Delete part", "acceptance", "1.1.1.1", 0);
fTemp = g + jarSrc;
fileSource = getFolder("file:///", fTemp);	// append the jarSrc file to the 
path
logComment("The file pathway = " + fileSource);
err2 = File.remove(fileSource);
logComment("fileDelete returns = " + err2);
doItOrDie();

function doItOrDie() 
{ 
   if (0 == getLastError())
      performInstall();			// do the install here.
   else
      cancelInstall();
}

Comment 1

[Jimmy Lee]

Adding keyword pp.

Comment 2

[Jimmy Lee]

This was working for build 7/21/00 and failed on 7/24/00.

Comment 3

[Samir Gehani]

How about a file op on a folder spec object created by:
f = getFolder("Program", "filedelete.txt");
File.remove(f);

If this works still then the file ops are not as broken as suspected.  If this 
does not work, we should consider this for nsbeta3.

Comment 4

[Samir Gehani]

Orthogonal to this bug, it's non-intuitive to say File.remove(f).  It would be 
more intuitive to say f.remove().  Looking at the code, this is not possible.  
All File operations work like static methods on the File class rather than 
methods on object instances.  We should consider changing this at some point.

Comment 5

[Daniel Veditz [:dveditz]]

It would be interesting to see what fTemp was, but in any case any time you are 
tempted to do "fileObject + string" you are veering into unsupported territory.

The following would work:
  fileSource = getFolder(g,jarSrc);

But if you want to use getfolder("file:///",x) then you must make sure x is in 
a supported URL form. If you can type it into the URL bar and have it work then 
we'll support it, otherwise we won't.

There may be a null ending problem on the file object string on macs, that's 
why I want to know what fTemp is because that may be where the bug is. Adding a 
file object and a string should result in a valid string, but a bug there would 
have nothing to do with the file:/// getFolder() target.

Comment 6

[Daniel Veditz [:dveditz]]

Re: Samir's point. We talked about turning these into true file objects and 
doing operations on themselves but Doug talked me out of it. I think we're kind 
of stuck with things the way they are, unfortunately.

Part of the problem is that File object operations are sometimes queued and 
sometimes not, and when they are queued what happens to the object if you then 
try to do another operation on it? It was somewhat simpler to explain as global 
operations, using "File." only to chop up the namespace a little.

Comment 7

[David Epstein]

The problem is not happening when appending the file to the folder object. It 

happens when using this appended pathway (fTemp) with the fileURL in getFolder. I 

updated 2 scripts with log comments for fTemp and they return the complete 

pathway for fTemp on Mac. a_fileop_filecopy and a_fileop_filedelete.



Please note that prior to this breakage on Mac, fileops were working correctly 

cross platform. We were using this segment in the fileOps after conferring with 

development:

 fTemp = f + jarSrc;

 fSource = getFolder("file:///", fTemp);

It was our understanding that this is supported. I even asked whether or not we 

should be using a '/' between f and the jarSrc file, but the decision was to not 

use it. So if we're not supporting this direct additive method, we'll have to 

change all of these fileop scripts.



I did try using fileSource = getFolder(f, jarSrc) and this works fine cross 

platform. I created a_fileop_filecopy_getf.xpi and a_fileop_filedelete_getf.xpi.



Here are the relevant log files:



-------------------------------------------------------------------------------

http://jimbob/jars/a_fileop_filedelete.xpi  --  08/07/2000 14:32:06

-------------------------------------------------------------------------------



     Acceptance: a_fileop_filedelete

     -------------------------------



     ** addFile returns = 0

     [1/1]	Installing: Macintosh HD:Netscape Folder:filedelete.txt



     Install completed successfully

     The File Delete part

     --------------------



     ** fTemp pathway = Macintosh HD:Netscape Folder:filedelete.txt

     ** The fileURL pathway = Macintosh HD:Netscape Folder:

     ** ERROR (-216): Deleting file: Macintosh HD:Netscape Folder

     ** fileDelete returns = -216



     Install cancelled by script

     Finished Installation  08/07/2000 14:32:06



-------------------------------------------------------------------------------

http://jimbob/jars/a_fileop_filecopy.xpi  --  08/07/2000 12:35:30

-------------------------------------------------------------------------------



     Acceptance: a_fileop_filecopy

     -----------------------------



     ** addFile returns = 0

     [1/1]	Installing: Macintosh HD:Netscape Folder:Components:filecopy.txt



     Install completed successfully

     ** fTemp pathway = Macintosh HD:Netscape Folder:Components:filecopy.txt

     The File Copy part

     ------------------



     ** fileSource pathway = Macintosh HD:Netscape Folder:

     ** fileTarget pathway = Macintosh HD:Netscape Folder:chrome:

     ** ERROR (-233): Copy File: Macintosh HD:Netscape Folder to Macintosh 

HD:Netscape Folder:chrome

     ** File.copy returns = -233



     Install cancelled by script

     Finished Installation  08/07/2000 12:35:31



-------------------------------------------------------------------------------

http://jimbob/jars/a_fileop_filecopy_getf.xpi  --  08/07/2000 13:59:41

-------------------------------------------------------------------------------



     Acceptance: a_fileop_filecopy

     -----------------------------



     ** addFile returns = 0

     [1/1]	Installing: Macintosh HD:Netscape Folder:Components:filecopy.txt



     Install completed successfully

     The File Copy part

     ------------------



     ** fileSource pathway = Macintosh HD:Netscape Folder:Components:filecopy.txt

     ** fileTarget pathway = Macintosh HD:Netscape Folder:chrome:

     ** File.copy returns = 0

     [1/1]	Copy File: Macintosh HD:Netscape Folder:Components:filecopy.txt to 

Macintosh HD:Netscape Folder:chrome



     Install completed successfully

     Finished Installation  08/07/2000 13:59:42

Comment 8

[David Epstein]

the bugzilla trickster gods double-spaced my reply! Well, it's easier to read.

Comment 9

[Daniel Veditz [:dveditz]]

getFolder(<something>) + filename should yield a perfectly valid path string in 
the native machine format, you should not have to append a slash or 
platform-specific delimiter between the folder and the filename. However, this 
gives you a path string in the native format which is not useful for much of 
anything except printing or some other display. In particular it's not going to 
be able to be fed to any of the XPInstall commands that require file objects.

Note that fTemp was drive:folder:folder:file when getFolder subpaths must be 
delimited by '/'. Anything that works beyond that (e.g. windows appears to 
accept file URLs with window delimiters) is simply the underlying Necko being 
generous. In the file:/// getFolder case I simply combine the two parts and 
then feed it into the system. 
"file:///Macintosh HD:Netscape Folder:Components:filecopy.txt" probably isn't a 
valid file URL.

Comment 10

[Jimmy Lee]

Moving to a kinder, gentler form.  Marking Verified!

Comment 11

[Michael Lefevre]

fixing null OS field on old bugs