1216766 - Firefox fails to update when there are files with too long names in Firefox directory

Status: UNCONFIRMED

(Toolkit :: Application Update, defect)

Description

[necrokris]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:41.0) Gecko/20100101 Firefox/41.0
Build ID: 20151014143721

Steps to reproduce:

It affected Firefox at least 39. It was on Windows 7 64 bit. 
1. Create any file with name exceeding limits (path+filename is over 260 chars) in Firefox directory, in the place where firefox.exe is
2. Try to update Firefox to the new version


Actual results:

1. Firefox tries to download small update
2. Firefox tries to download full update
3. Firefox says that update failed


Expected results:

1. Firefox updates
OR
1. Firefox gives detail about problems

Comment 1

[Loic]

(In reply to necrokris from comment #0)

> 1. Create any file with name exceeding limits (path+filename is over 260
> chars) in Firefox directory, in the place where firefox.exe is

How to do that? On Win 7, the filename is shortened when the path+filename exceeds 260 chars.

Comment 2

[necrokris]

(In reply to Loic from comment #1)
> (In reply to necrokris from comment #0)
> 
> > 1. Create any file with name exceeding limits (path+filename is over 260
> > chars) in Firefox directory, in the place where firefox.exe is
> 
> How to do that? On Win 7, the filename is shortened when the path+filename
> exceeds 260 chars.

That's true, that's why I find it very minor bug. It can be created either by 3rd party tool/script which doesn't obey limits or... Well, I don't know any built-in way yet. I'll ask people and as soon as I'll get answer, I'll tell you.

In my case it was yt-download with wrong file naming scheme, so it created file which exceeded the limits. I ran this tool from Open With (Fx plugin) so starting dir was Firefox executable dir. That's why it's very, very rare, but still possible to occur in real world. Problems with deleting such file (Windows won't allow it) could be a reason to ignore it and keep file in browser dir.

Comment 3

[necrokris]

As Stack Overflow users suggets, it might be impossible to do it purely in command line. I'm citing SO user IInspectable:
"The easiest way is to call the Unicode version of the CreateFile API, prefixing the filename with \\?\:

std::wstring filename = L"\\\\?\\C:\\<insert up to 32k characters>";
::CreateFileW( filename.c_str(), GENERIC_WRITE, 0, NULL, CREATE_ALWAYS,
               FILE_ATTRIBUTE_NORMAL, NULL );

Keep in mind, though, that the shell (namely Explorer.exe) imposes a pathname limit of 260 characters. A file created with a pathname that exceeds this limits cannot be opened, copied, moved, or even deleted using the shell, or any tool using the Shell Path Handling Functions. You can delete the file calling the DeleteFile API."

Here's the link to my question and other answers.

Comment 4

[Loic]

Any tool using this API? We need a simple way to reproduce the bug.

Comment 5

[necrokris]

(In reply to Loic from comment #4)
> Any tool using this API? We need a simple way to reproduce the bug.

Good news. Harry Johnston von StackOverflow gave this way using just command line:
"robocopy automatically supports long paths, so one simple solution would be to create a file with a long name (221 characters+) in the root directory and then say

robocopy c:\ "C:\Program Files (x86)\Mozilla Firefox" longname*

(Here I'm assuming the name of the file starts with longname.)"

Comment 6

[necrokris]

Attachment: bug1216766.bat

Batch script to create and delete test file. It uses only Windows built-in tools - mostly robocopy. Default path is set to "C:\Program Files (x86)\Mozilla Firefox". If it's other, please change it in line 4. 

Script contains menu, so there's no command options/parameters.

Comment 7

[Loic]

Thanks for the script.
I noticed a side-effect of your script, the destination folder becomes hidden after moving the file with the long filename. I don't know why.

Anyway, I tested myself with an outdated standalone Nightly (like http://ftp.mozilla.org/pub/firefox/nightly/2015/06/2015-06-04-03-02-05-mozilla-central/firefox-41.0a1.en-US.win32.zip) and a custom profile. The build downloads the full update but fails to apply it in the background, but Firefox displays the error (!) in the hamburger menu and offers to download the update manually from the official website.

So I don't see any issue, it's the normal behavior because FF fails to move the long file and the update is not applied.

Comment 8

[necrokris]

(In reply to Loic from comment #7)
> Thanks for the script.
> I noticed a side-effect of your script, the destination folder becomes
> hidden after moving the file with the long filename. I don't know why.
> 
> Anyway, I tested myself with an outdated standalone Nightly (like
> http://ftp.mozilla.org/pub/firefox/nightly/2015/06/2015-06-04-03-02-05-
> mozilla-central/firefox-41.0a1.en-US.win32.zip) and a custom profile. The
> build downloads the full update but fails to apply it in the background, but
> Firefox displays the error (!) in the hamburger menu and offers to download
> the update manually from the official website.
> 
> So I don't see any issue, it's the normal behavior because FF fails to move
> the long file and the update is not applied.

[points quoted from Mozilla Bugzilla] 
User experience principles (named UXP in this post): 
UXP a) interfaces should proactively help users recover from both user errors and technology errors
UXP b) interfaces should proactively try to prevent errors from happening
UXP c) interfaces should be as efficient as possible, minimizing the complexity of actions and the overall time to complete a task
UXP d) [not a quote - own feelings] if software can't prevent error, yet it knows where lies the problem, it should give detailed description

It's not obvious that Fx updater (but not installer) tries to move files created by user. I still don't know why, but it doesn't matter. From user's view - why I can download new version and install it, yet Fx can't reinstall itself? That's not obvious as well. I even didn't have a clue about existence of such files in app dir, so I couldn't know fail reason. _Other more probable scenario_ is file system error (HDD failure or just power outage) and there will be unmovable files as well (UXP a). 

The lack of similar reported cases could be also caused by people not able to help/not knowing what's the cause, cause these debug difficulties. One can find unresolved cases because people weren't able to find what causes that behavior.

I noted in bug report that Firefox displayed error message, but it's a matter of "Failed" vs. "failed because" (UXP d). That way typical user or newbie is forced to download manually every new version (UXP c). Sometimes there are a few security fixes in a row and much longer process of installing new version over new can cause users to ignore updates or switch for other browsers (as newbies often aren't so tied to their env as powerusers are).

You say that "it's the normal behavior" but paradoxically if Fx would crash, user would know the reason - by error reporting and allowing user to see discussion about similar crashes!

Non-consistency (from user point of view, not coder) also complicates debugging. Faulty file causes update (even full one) to fail, yet Firefox work very well. It also shows that one part of Fx deals with it well, so why other couldn't?

As I shown it doesn't have to be users fault to have such files. Yet even if it would, Fx should give friendler message (UXP a). Or most desired resolution - ignore these files, like full install do (UXP b).