Closed Bug 454062 Opened 16 years ago Closed 16 years ago

Files with invalid filenames get generated in profile directory

Categories

(SeaMonkey :: General, defect)

Product:
SeaMonkey
Component:
General
Version:
SeaMonkey 1.1 Branch
Platform:
x86
OS/2
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
RESOLVED INCOMPLETE

People

(Reporter: ok34, Unassigned)

Details

Attachments

(4 files)

Illegal filenames
37.79 KB, image/png
Details
Directory with rogue filenames
968 bytes, application/zip
Details
Screen shot of directory with smilies
9.65 KB, application/zip
Details
Operating System's view of same directory
10.60 KB, application/zip
Details 
User-Agent:       Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.8.1.15) Gecko/20080622 SeaMonkey/1.1.10 (PmW)
Build Identifier: Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.8.1.15) 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.
Attached image 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
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)?
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.zip 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.
Additionally, can you find out what the "invisible" files contain? Tools like the typ_os2 (http://hobbes.nmsu.edu/download/pub/os2/util/archiver/typ_os2.zip) or file (http://hobbes.nmsu.edu/download/pub/os2/util/file/file330.zip) programs should be able to tell you.
No more answers -> incomplete.

Oliver, if at some point you can provide the info we asked for, please reopen the bug.
Status: UNCONFIRMED → RESOLVED
Closed: 16 years ago
Resolution: --- → INCOMPLETE
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.
Status: RESOLVED → UNCONFIRMED
Resolution: INCOMPLETE → ---
Directory containing rogue filenames. Salt numbers have been manually removed using E.
Screenshot showing file upload window with smilies instead of filenames in profile directory.
This is the view of eComStation on the same directory: Plain normal.
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...
Oops, just salt is visible. Is there a way to remove an attachment, I could find one? Thanks.
TYP_OS cannot open the rogue files, and FILE coredumps...
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 http://hobbes.nmsu.edu/download/pub/os2/apps/editors/hexedit2.zip
  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.
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.)
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.//home.netscape.com/NC-RDF

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:1.8.1.15) 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?
> http://svn.netlabs.org/fat32
According to FTP site, update looks to be done twice in 2008. Do you use newest FAT32 driver?
> ftp://ftp.netlabs.org/pub/fat32/
>  File: fat32_0912.wpi  2008/04/16 0:00:00
>  File: fat32_0912.zip  2008/04/16 0:00:00
>  File: fat32_09121.wpi 2008/05/05 0:00:00
>  File: fat32_09121.zip 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.
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...
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...
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?
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.
Status: UNCONFIRMED → RESOLVED
Closed: 16 years ago → 16 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: