I'm using FireFox Portalbe v 2.0.0.8 on a Kingston DataTraveler 1GB USB Flash Drive.
I noticed that FireFox "hangs" quite a bit on one of my workstations. I experienced this problem on FireFox v2.0.0.6, so I upgraded to FireFox Portable v2.0.0.8 yesterday. I did not remove/reinstall.
I use FireFox on 3 workstations. Two of the workstations have USB 2.0 interfaces and the IBM T30 Laptop has a USB 1.0 interface. On one workstation I noticed the "hanging" programs (Thunderbird hangs too) and found it irritating.
On the offending workstation I used the Microsoft Process Monitor to view reads/writes to the FireFoxPortable directory. I noticed that the application "hangs" for about 2 or 3 seconds whenever an IRP_MJ_CREATE operation receives a NAME COLLISION response.
As a matter of fact, while writing this message I'm receiving a NAME COLLISION error just about every read/write attempt to the flash drive while writing this message.
I have done the following to improve performance:
1) Configured the removable disk for Performance (which requires that I safely remove the disk on Windows XP SP-2)
2) Disable Cache, History, and Form Saving
3) Disable Session Restore/Undo Close Tab
4) Disabled Anti-Phising
5) Disabled all Extensions (Themes and FoxMarks)
6) Disbled JavaScript and Java (ouch!)
None of these changes improved the "hanging" problem.
I am certain the problem is not in the Flash Drive itself because it works well on the other two machines. I'll double check this again this evening because I'm aware that Flash drives can deteriorate.
I don't think it is the version of FireFox that is causing the problem. I don't think it is the Java because the application seems to work well on the other two machines.
Does anyone have any suggestions to stop the NAME COLLISION problem? If you know of another utility that would let me see exactly what Names are colliding it might help me track down the culprit.
Thanks in advance,
Brad
Visit the Community page
Join our forums
Subscribe to our email newsletter
Subscribe with RSS
Follow us on Facebook
Follow us on LinkedIn
Follow us on Twitter
Follow us on Mastodon
Follow us on BlueSky
I still get NAME COLLISION results from CreateFile calls (IRP_MJ_CREATE). After some more research, this happens on all three (3) of my PCs. I tried another removable media device and still get the same issues. Mozilla portable hangs because of NAME COLLISION return codes.
I just copied the PortableApps to my local C:\ drive. While the "hanging" is not noticeable because the disk drive is much faster than an external USB 2.0 device, the NAME COLLISION issue is still visible in the Process Monitor utilty.
As I write this there are repeated NAME COLLISIONs occurring. Must be something to do with this Form. Hmmm.
I also tried performing a clean install on two different removable media (a 128MB SD card and my 1GB DataTraveler) as well as the local C:\ drive.
FireFox v2.0.0.8 from Mozilla.org doesn't produce nearly as many of these return codes. Unfortunately, I am not using the full-version of FireFox on my portable drive.
Anyone else noticing "hanging" caused by NAME COLLISION returns from CreateFile calls via IRP_MJ_CREATE operations?
Thanks,
Bradley Jennings
putting "knowledge" in "Teknowledgey".
since no one else replied.
I haven't gotten this type of error ever. ffp2.008, win xp.
Don't be an uberPr∅. They are stinky.
I was curious why the PFF2.0.0.8 would "hang". At first I thought it might be a Flash Drive failure. So, I downloaded the ProcMon utility from Microsoft. It let me see the ins-and-outs to my Portable Apps directory and all files. This is how I saw the response code "NAME COLLISION" and associated it with the "hanging".
I tried the FireFox PortableApps on my local C:\ drive and the "NAME COLLISION" messages were apparently still happening. So, I figure the message isn't caused by a problem on the Flash Drive or SD Card. Oddly, the full version of FireFox v2.0.0.8 (from http://www.mozilla.org) doesn't create as many (if any) of the "NAME COLLISION" responses from IRP_MJ_CREATE message. However, I haven't tried running the full v2.0.0.8 version on my memory stick.
Hey, I just noticed that FireFox v2.0.0.9 is available. I wonder if the PortableApps version of FireFox v2.0.0.9 will eliminate this issue.
Thanks again!
Bradley Jennings
putting "knowledge" in "Teknowledgey".
The NAME COLLISION Message does not appear when running my PFF2.0.0.8 on Windows 2000 Pro.
The Desired Access of "Read Data/List Directory, Synchronize,Disposition:Create,Options: Directory,Synchronous IO Non-Alert,Attributes: N, ShareMode: Read,Write,AllocationSize: 0" doesn't cause a NAME COLLISION error when using Windows 2000 Pro. This type of access causes an error on Windows XP SP-2. I've seen this appear on two separate Windows XP SP-2 PCs.
Hmmm. Windows XP problem? Makes using the Portable Apps almost unbearable. Bummer.
I wonder if using the Patched PortableApps launcher has anything to do with this.
Edit: Oops. I spoke too soon. It's still there. It just doesn't seem to cause the type of delay I experienced on Windows XP SP-2. In other words, the "Hang" isn't evident.
Bradley Jennings
putting "knowledge" in "Teknowledgey".
Is it all file names that are having this problem, or just one? Can you identify which directory it is happening in, or is it many?
If more than one, perhaps you can give an example?
MC
From the Event text of SysInternals Process Monitor (procmon.exe) it appears the NAME COLLISION result happens when a CreateFile operation is attempted on the Path F:\PortableApps. There is not file listed in the event log. Just the directory F:\PortableApps.
The Event detail includes the following information:
Sequence: 574879
Date & Time: 11/4/2007 7:38:16 PM
Event Class: File System
Operation: CreateFile
Result: NAME COLLISION
Path: F:\PortableApps
TID: 136248
Duration: 0.0002249
Desired Access: Read Data/List Directory, Synchronize
Disposition: Create
Options: Directory, Synchronous IO Non-Alert
Attributes: N
ShareMode: Read, Write
AllocationSize: 0
I noticed whenever that whenever the application "hangs", procmon.exe records the NAME COLLISION event.
The procmon.exe utility also records a number of SUCCESS results when trying to Open F:\PortableApps directory.
Sequence: 575049
Date & Time: 11/4/2007 7:38:16 PM
Event Class: File System
Operation: CreateFile
Result: SUCCESS
Path: F:\PortableApps
TID: 136248
Duration: 0.0002265
Desired Access: Read Data/List Directory, Synchronize
Disposition: Open
Options: Directory, Synchronous IO Non-Alert
Attributes: n/a
ShareMode: Read, Write
AllocationSize: n/a
OpenResult: Opened
Notice the durations is similar in both examples. I'm running Windows 2000 Pro and do not notice a "hang" or "pause" when the NAME COLLISION message occurs.
It seems obvious that Name Collisions occur when the application is trying to create a file that already exists. Perhaps a "pause" happens because of the way USB 2.0 Flash drives work. Maybe the "pause" is more evident on Windows XP SP-2 than Windows 2000 Pro because of the drivers. Or, it may be that I'm using different chipsets on the Windows 2000 Pro machine. Who knows? I may be barking up the wrong tree.
I tried opening my locally installed FireFox v2.0.0.9 (yes, it has been upgraded automatically) with an option to use the profile on the "F:\PortableApps\FirefoxPortable\Data\Profile" directory. I did not experience any NAME COLLISION messages while monitoring FireFox running this way.
Thanks,
Bradley Jennings
putting "knowledge" in "Teknowledgey".
I just installed FFPE fresh, and I do see the NAME COLLISION message. It seems most often on mine it is near the beginning in a sequence where the last step is to open or create a new file, usually in F:\PortableApps\FirefoxPortable\Data\profile\, like cookies.txt or sessionstore.js, or the same name with -1. Can you follow the progression down to something like that? Are you able to tell if the pause is on one particular file task, or is it every time it goes through that progression? Can you tell if the pause is at the first NAME COLLISION line, or if it is at the end of the sequence that just happens to start with NAME COLLISION? The time column should be able to tell you that.
I'm guessing that the programmers said "write to or create F:\PortableApps\FirefoxPortable\Data\profile\sessionstore.js" and the command triggers the operating system to check each step in the path; the programmers probably expect each of the folders to be there, meaning that the NAME COLLISION results are expected, but something is trying each one in turn. As you can see on the other machines, it doesn't usually cause a huge delay (though it certainly doesn't seem very efficient to be going through those 15 steps every couple of seconds).
By the way, on my XP(SP2) that sequence, from the first "Create File", takes .003 seconds. I haven't noticed a pause in there, though it does seem sometimes to go through the same sequence several times a second.
I'm just wondering if there is any pattern to the ones that cause the lock up -- one particular file where the pause is more noticeable.
The other thing that might cause that sort of lockup is e.g. an antivirus program that is holding up everything until it has had a chance to scan the file. That would likely not show up in the main ProcMon list as such, since it has to be integrated into the kernel to do much good. Have you tried eliminating those sorts of things? If that were the case I might expect a .js (javascript) file to be scanned, while cookies.txt might not, if that yields a clue. Just a thought...
MC
I just fiddled around with this issue again this morning and discovered that FireFox hangs or pauses when executed through the PortableApps menu shortcut. It appears that the NAME COLLISION occurs on the file
F:\PortableApps\FirefoxPortable\App\firefox\firefox.exe(where F: is the portable drive). This NAME COLLISION occurs numerous timed during a Portable FireFox session.If FireFox portable is invoked via the command line
F:\PortableApps\FirefoxPortable\App\firefox\firefox.exe -profile=F:\PortableApps\FirefoxPortable\Data\Profilethe NAME COLLISION only occurs three times during startup, and does not appear again. FireFox runs without a hicup.I believe the NSIS (Nullsoft Scriptable Install System) wrapper is attempting to create the firefox.exe executable numerous times during the FireFox session, and is failing to do so because the executable is in a read-only state during execution.
The FireFox portable is hard-wired to the firefox directory where the firefox.exe file resides. If you try to change the firefox directory name then the FireFoxPortable.exe will produce an error.
Bradley Jennings
putting "knowledge" in "Teknowledgey".
This is nothing to do with any code we do. It could be that Firefox itself is more likely to have this issue when used with the -profile switch. Either way, nothing we can do about it. Perhaps 2.0.0.9 fixes this. FFPE 2.0.0.9 is being packaged for release now.
Sometimes, the impossible can become possible, if you're awesome!
news about any of the other apps?
He is giving you a finger.........and you're asking for the whole arm!
*Looks angrily at Steve* :evil:
"What about Love?" - "Overrated. Biochemically no different than eating large quantities of chocolate." - Al Pacino in The Devils Advocate
To hell with the arm, I want the whole body!
"If you're not part of the solution, you're part of the precipitate."
"What about Love?" - "Overrated. Biochemically no different than eating large quantities of chocolate." - Al Pacino in The Devils Advocate