Files with invalid filenames get generated in profile directory



10 years ago
9 years ago


(Reporter: Oliver Kluge, Unassigned)


SeaMonkey 1.1 Branch

Firefox Tracking Flags

(Not tracked)



(4 attachments)



10 years ago
User-Agent:       Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv: Gecko/20080622 SeaMonkey/1.1.10 (PmW)
Build Identifier: Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv: Gecko/20080622 SeaMonkey/1.1.10 (PmW)

In the profiles directory I found several files with invalid filenames, seemingly  of zero length or characters not displayed by OS command line and GUI.

Reproducible: Didn't try

Steps to Reproduce:
1.Since this happens on its own, I cannot do anything to reproduce it, but I can watch if new files come up

All file dates coincide with the usage of the build specified above. This behaviour has not been observed with earlier builds, and version 1.1.11 is just about to be installed here.

I set this bug to "major" since this has some possibility of breaking some file systems, because a file "" in the path \foo\path could be (mis)interpreted as access to the _file_ \foo\path containing the directory information.

Add'l info: filesystem in use here is FAT32, Seamonkey itself resides in HPFS.

Comment 1

10 years ago
Created attachment 337289 [details]
Illegal filenames

A command line dir showing the rogue files.
There is a possibility that the problem was fixed between when Sm 1.1.10 and 1.1.11 were released. I suggest you install the latter, and watch if more of these files crop up. If they don't, then after some "reasonable" time this bug can be resolved WORKSFORME.
Version: unspecified → SeaMonkey 1.1 Branch

Comment 3

10 years ago
Oliver, do you have any extensions installed?

Tony, unless you have a specific bug in mind, I really doubt that there were any relevant changes since 1.1.10...

Don't remember having heard about such a bug before. IIRC all the files in the profile get created through the nsLocalFile/nsLocalFileOS2 interface which prohibits creation of files with empty names, so I have no clue where even to put debug output...
Maybe the filenames aren't actually empty, but made up of characters which don't display? Spaces, maybe (0x20), and/or no-break spaces (0xA0)? Oliver, do you have any utility program on your machine which is able to display a directory in hex (or, even better, in hex and alpha side-by-side)?

Comment 5

10 years ago
Indeed. Oliver, perhaps you can redirect the directory output to a file, zip it up and attach here, so that binary characters stay unchanged? Like
   dir <salt>.slt\* > dir.out
   zip -m dir.out
(If you don't want the salt numbers visible publically, you can send that to me personally.)
By the way, which tool were you using to display the directory in the screenshot? Normal "dir" does not say "Press ESC to quit" etc.

Comment 6

10 years ago
Additionally, can you find out what the "invisible" files contain? Tools like the typ_os2 ( or file ( programs should be able to tell you.

Comment 7

10 years ago
No more answers -> incomplete.

Oliver, if at some point you can provide the info we asked for, please reopen the bug.
Last Resolved: 10 years ago
Resolution: --- → INCOMPLETE

Comment 8

10 years ago
Sorry for not answering. Thank you for your patience. The amount of time I have for Seamonkey is unfortunately very limited, so I tend to not monitor bugs within Bugzilla, but by keeping an eye on the incoming mail from Bugzilla.

But strangely enough I wasn't notified by Seamkoney about the mails that your postings produced. The mails came in correctly. Since I do receive very many mails I sort them into folders, and one folder is dedicated to Bugzilla. But Seamkonkey did not mark the folder in bold type and with the unread mail counter. Today I migrated to SM 1.1.13 (skipping 12), and I do archive my mail on this occasion. And magically when I clicked on the Bugzilla folder it got bold and displayed 26 unread Bugzilla mails... Maybe I should check whether this is a bug already reported or not.

But I got sidetracked. There are new files with illegal names, and judging by their timestamps they must have been produced by SM 1.1.11.

I will try to take the time to install the tools you suggested to investigate into the contents of these files.
Resolution: INCOMPLETE → ---

Comment 9

10 years ago
Created attachment 348329 [details]
Directory with rogue filenames

Directory containing rogue filenames. Salt numbers have been manually removed using E.

Comment 10

10 years ago
Created attachment 348330 [details]
Screen shot of directory with smilies

Screenshot showing file upload window with smilies instead of filenames in profile directory.

Comment 11

10 years ago
Created attachment 348331 [details]
Operating System's view of same directory

This is the view of eComStation on the same directory: Plain normal.

Comment 12

10 years ago
I have created the attachment. By the way, regular DIR does produce the text "press ESC to quit" - if you have 4OS2 and use the /p switch...

It gets even stranger. I could not upload the ZIP in the first place! I was unable to navigate to my profile directory using Seamonkey! When I came to the base directory where the XXX.slt resides, I did not get the directory's contents, but 50 directory icons with smilies as directory names... The operating sytem's view of the directory is normal, as you can see on both the text directory and the second screenshot from OS/2 GUI...

For a moment I thought about the possibility that somehow the directory could be corrupt (file system is FAT32 due to necessity to share with Windows), but I had several checks of this volume by Windows. Normally Windows only finds files that are left over from a Seamonkey/Flash crashing (usually downloads.rdf, bookmark and cookie files) but I have never had serious complaints from Windows... I thought the file upload dialog in Seamonkey would come from the operating system? But eCS views the directory correctly... 

Maybe the rogue filenames aren't empty after all but contain really weird characters (>220) that irritate the file selection dialog, but not the operating system as such...

Comment 13

10 years ago
Oops, just salt is visible. Is there a way to remove an attachment, I could find one? Thanks.

Comment 14

10 years ago
TYP_OS cannot open the rogue files, and FILE coredumps...

Comment 15

10 years ago
Oliver, attachments cannot be removed. But don't worry, the salt is not so secret. It's just a simple way of making scripted attacks harder.

Oh, so you are using 4OS2. That's what I meant with not "normal"... Perhaps you should also try that in plain CMD without using 4OS2. Just to exclude one more possibility.

Two things:

- The filenames in the file in attachment 348329 [details] appear to be all just two
  spaces. I don't know if that is because E messed the file up (could well
  be, E is bad for such things) or not. You could check yourself in a Hex
  editor (such as
  or similar). Just use the original redirected DIR output and load that
  file and check if the filenames consist of other than 0x20 characters.

- As the filenames have timestamps it occurred to me that you can check in
  your history (when sorted by the "Last Visited" column) which webpage 
  you visited at that time. Perhaps that way you find something common
  between all the instances.

Comment 16

10 years ago
Oh, I see that you history.dat is 0 bytes. So you don't store history. Then forget my last suggestion.

Actually, if the filenames really are all two spaces, then something is wrong with your filesystem. Otherwise they shouldn't be able to coexist...
(In reply to comment #16)
> Actually, if the filenames really are all two spaces, then something is wrong
> with your filesystem. Otherwise they shouldn't be able to coexist...

Output of "DIR Command" at Command Prompt is probably changed to string which is displayable at Command Prompt window. To see real binary data of the file names, please try "check by REXX". You can probably see HEX-DECIMAL notation of the file names by combination of SysFileTree() and C2X() of REXX. And you can probably check HEXA-DECIMAL notation of first NNN bytes of the files by CHARIN() and C2X() of REXX. Further, you can check them also on MS Win with same REXX Script, if you install "Open Object REXX"(open source/charge free version of "Object REXX") on MS Win.

To Oliver Kluge(bug opener):
Can you write REXX script by your self? If not, I can provide REXX script for you. (I was an expert of REXX coding for VM/CMS, OS/2, CICS etc. of IBM systems in the past.)

Comment 18

10 years ago
Okay, I've done some research. It has been more than a decade since the last time I analyzed directories in hex... Same goes for Rexx programming by the way. I used to that in the 90s.

First I checked Linux and Windows. Linux completely (!) ignores the rogue files. They are not displayed at all, not in bash not on Gnome... Windows shows them, both on the command line and on the GUI. But it is unable to open any of them "file not found".

I used DFSee to check the directory in hex. Funny that E reports 2 spaces - actually they are all spaces: eight spaces filename, three spaces extension. E.g.

20 20 20 20 20 20 20 20    20 20 20 20 00 00 76 0E
F3 38 F3 38 08 00 77 0E    F3 38 01 D6 EE 3E 00 00

DFSee indicates extended attributes - that also contain spaces. The sector the directoy points to begins with

<?xml version="1.0"?>
<RDF=RDF xlmns:WC="http.//

This looks like it is downloads.rdf, as it points to a file that has been downloaded on the same date as the rogue directory entry. So to me this looks like a _valid_, but strange, directory entry, but of course there should not be more than one with identical filename, and even this one should be avoided because it's hard to access...
Questions to rule out problem of "FAT32 diver".

(In reply to comment #0)
> Build Identifier: Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv: Gecko/20080622 SeaMonkey/1.1.10 (PmW)
> Add'l info: filesystem in use here is FAT32, Seamonkey itself resides in HPFS.

To Oliver Kluge(bug opener):  
Does it means you use FAT32 driver for OS/2 provided by Netlabs?
According to FTP site, update looks to be done twice in 2008. Do you use newest FAT32 driver?
>  File: fat32_0912.wpi  2008/04/16 0:00:00
>  File:  2008/04/16 0:00:00
>  File: fat32_09121.wpi 2008/05/05 0:00:00
>  File: 2008/05/05 0:00:00
According to "FAT32.TXT", format in FAT32 on OS/2 looks to be possible.
Did you format the FAT32 partition under OS/2? Or formated by MS Win?
(In reply to comment #18)
> I used DFSee to check the directory in hex. Funny that E reports 2 spaces -
> actually they are all spaces: eight spaces filename, three spaces extension.
> E.g.
> 20 20 20 20 20 20 20 20    20 20 20 20 00 00 76 0E
> F3 38 F3 38 08 00 77 0E    F3 38 01 D6 EE 3E 00 00

This is "Short Entry" part of FAT32, and file name in it is "Sort File Name"(8.3 format). "DIR output at OS/2 Command Prompt" can be affected by;
 (A) File name part of usual "DIR" command output is "Long File Name".
 (B) Because of rule of "leading/trailing spaces are ignored",
     "DIR" at OS/2 command possibly displays two 0x20 for it.
     (On MS Win/XP, following error occurs when copy to 8*0x20+"."+3*0x20.)
>     C:\wada\TEST\@@@@\@@@>dir TXT*
>       2007/12/31  20:54  40 TXT.TXT
>     C:\wada\TEST\@@@@\@@@>copy TXT.TXT "        .   "
>       The system cannot find the path specified.
>          0 file(s) copied.

To Oliver Kluge(bug opener): 
Can you check binary of file name in "Long enrtries" of FAT32?
If both of long/short name exist & consist of ASCII characters only, DIR output at "OS/2 command prompt" & DIR output at "MS/DOS command prompt" can be used to check it.

Comment 21

10 years ago
This is FAT32 0911, I will update it to check whether this is the source of error. Version history indicates nothing in 0912 that could possibly fix such behaviour (mostly USB related bug fixing, and a CHKDSK fix), but maybe 09121 changed something:

"Fixed the problem that a program trying to READ/WRITE from/to memory
object with OBJ_ANY attribute is crashed. But READ/WRITE performance
is decreased."

You know the code.. Is this related? What bothers is the statement that performance will decrease - performance of FAT32 is already extremely low if you have a drive > 100 GByte with very many files in it... (FAT 32 is still the  one and only file system that can be shared between OS/2, Linux and Windows...)

Regarding your question: I formated this volume under Linux. So far there is no other problem with this and the second volume that runs on FAT 32. Occasionally when Seamonkey crashes (mostly due to Flash) Windows will find unlinked downloads.rdf, cookie, history and bookmark files. No other file system problems ever for 1,5 years...

DFSee showed me a long file name entry, too. It also contained spaces only...

Comment 22

10 years ago
It occurred to me that I have no clue how one can create a file with only spaces in its name on OS/2. It isn't possible with any shell or editor I have nor with the WPS.

So I wrote two C test programs using fopen() and DosWrite(). I get only failures from fopen() and the return code of DosOpen() is either 3 (ERROR_PATH_NOT_FOUND) or 5 (ERROR_ACCESS_DENIED) depending on file system (I tried JFS, HPFS, FAT and FAT32; the latter is with driver version 0.9.10). So I still don't know how...

Although I cannot help in tracking down the problem, I'm very curious to learn how to do that. In case you find out...

Comment 23

10 years ago
Thanks for testing. Well, maybe there is no "normal" way to produce such names. But we're talking about abnormal behaviours, right?

Since downloads.rdf is involved, which to my knowledge remains open for writing all the time while Seamonkey runs, maybe it is an interaction between a Flash-based crash and FAT32 not acting correctly when the opener of a file handle terminates abnormally?

I checked my POPUPLOG.OS2. It contains many crashes of CACHEF32.EXE (c000005) - but they do not coincide with the timestamps of the rogue files. And frankly I cannot remember having so many OS crashes? Can it be that CACHEF32 can crash without crashing the OS?

Comment 24

9 years ago
In the meantime v0.9.13 of the FAT32 driver appeared, maybe that fixes the behavior for you?

For the moment I resolve this incomplete again, to get this off the radar. And because this looks a lot like a problem outside Mozilla code.

Oliver, as usual that shouldn't keep you from reopening again if you find out anything else.
Last Resolved: 10 years ago9 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.