bugzilla.mozilla.org has resumed normal operation. Attachments prior to 2014 will be unavailable for a few days. This is tracked in Bug 1475801.
Please report any other irregularities here.

GetFolder: Adding component fails with "Chrome" as target folder with subdirectory

VERIFIED FIXED in M10

Status

Core Graveyard
Installer: XPInstall Engine
P3
normal
VERIFIED FIXED
19 years ago
3 years ago

People

(Reporter: Jimmy Lee, Assigned: Cathleen)

Tracking

Trunk
All
Windows NT

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

19 years ago
Build: 6/9/99 SeaMonkey build

1. Trigger http://jimbob/jars/a_getfolder_2_chrome.jar
2. Using the form:
   f = Install.GetFolder("Chrome", "getfolder_chrome");

RESULT:
From the applications directory, "Chromegetfolder_chrome" is created as a
subdirectory.  The component, "smrtupdt.txt", is not installed.  In a separate
test, I tried using "chrome" //lower case 'c'  as the target folder, but the
result was the same regardless of case.

The Install.log shows:
---------------------------------------------------------------------------
Acceptance: a_getfolder_2_chrome
---------------------------------------------------------------------------

Starting Installation at 06/10/1999 10:30:04

Item [1/1]Installing:
C:\ProgramFiles\moz69\x86rel\Chromegetfolder_chrome\smrtupdt.txt

Finished Installation  06/10/1999 10:30:05

EXPECTED RESULT:
"getfolder_chrome" is a subdirectory of "chrome" which is a subdirectory of the
application directory.  "smrtupdt.txt" is installed in "getfolder_chrome".  The
Install.log reflects the proper directory where the component is installed.
(Reporter)

Comment 1

19 years ago
***Correction: The component, "smrtupdt.txt", is installed.
(Reporter)

Comment 2

19 years ago
Behavior is fine if no subdirectory is passed from GetFolder
(f = Install.GetFolder("Chrome");)

http://jimbob/jars/a_getfolder_2_chrome_nosubdir.jar
(Assignee)

Updated

19 years ago
Target Milestone: M10
(Assignee)

Comment 3

19 years ago
setting target milestone to M10

Updated

19 years ago
Assignee: dougt → dveditz

Comment 4

19 years ago
Here is the diff that needs to be applied to fix these bugs (6711, 7905, 7906).
Since I doubt the tree will be open anytime soon and I leave on vaction in three
days, dveditz will check these fixes in.

Index: nsInstallFolder.cpp
===================================================================
RCS file: /cvsroot/mozilla/xpinstall/src/nsInstallFolder.cpp,v
retrieving revision 1.9
diff -c -4 -r1.9 nsInstallFolder.cpp
*** nsInstallFolder.cpp	1999/05/27 21:02:50	1.9
--- nsInstallFolder.cpp	1999/06/16 15:17:16
***************
*** 97,117 ****
          it can be a Directory.  If it is the later, it must already exist and
of course be a directory
          not a file.
      */

!     nsFileSpec dirCheck(aFolderID);
!     if ( (dirCheck.Error() == NS_OK) && (dirCheck.IsDirectory()) &&
(dirCheck.Exists()))
      {
-         nsString tempString = aFolderID;
-         tempString += aRelativePath;
-         mFileSpec = new nsFileSpec(tempString);

!         // make sure that the directory is created.
!         nsFileSpec(mFileSpec->GetCString(), PR_TRUE);
!     }
!     else
!     {
!         SetDirectoryPath( aFolderID, aRelativePath);
      }
  }


--- 97,127 ----
          it can be a Directory.  If it is the later, it must already exist and
of course be a directory
          not a file.
      */

!     SetDirectoryPath( aFolderID, aRelativePath);
!
!     if (mFileSpec == nsnull)
      {

!         nsFileSpec dirCheck(aFolderID);
!         if ( (dirCheck.Error() == NS_OK) && (dirCheck.IsDirectory()) &&
(dirCheck.Exists()))
!         {
!             mFileSpec = new nsFileSpec(dirCheck);
!
!             if (aRelativePath.Length() > 0)
!             {
!                 nsString tempPath(aRelativePath);
!
!                 if (aRelativePath.Last() != '/' || aRelativePath.Last() !=
'\\')
!                     tempPath += '/';
!
!                 *mFileSpec += tempPath;
!             }
!
!             // make sure that the directory is created.
!             nsFileSpec(mFileSpec->GetCString(), PR_TRUE);
!         }
      }
  }


***************
*** 271,279 ****
  		    default:
                  mFileSpec = nsnull;
  			   return;
  		}
! #ifndef XP_MAC
          if (aRelativePath.Length() > 0)
          {
              nsString tempPath(aRelativePath);

--- 281,289 ----
  		    default:
                  mFileSpec = nsnull;
  			   return;
  		}
!
          if (aRelativePath.Length() > 0)
          {
              nsString tempPath(aRelativePath);

***************
*** 281,289 ****
                  tempPath += '/';

              *mFileSpec += tempPath;
          }
- #endif
              // make sure that the directory is created.
          nsFileSpec(mFileSpec->GetCString(), PR_TRUE);
      }
  }
--- 291,298 ----
(Reporter)

Comment 5

19 years ago
Build 7/27/99

No longer seeing this problem.  Behaves as expected from WinNT, Win98, Linux,
and Macintosh.
(Assignee)

Updated

19 years ago
Status: NEW → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED
(Assignee)

Comment 6

19 years ago
Jimmy, I'm going to mark this bug as FIXED.
(Reporter)

Updated

19 years ago
Status: RESOLVED → VERIFIED
(Reporter)

Comment 7

19 years ago
Build 8/28/99

Done.

Comment 8

19 years ago
Bulk move of XPInstall (component to be deleted) bugs to Installer: XPInstall
Engine
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.