Cache.trash files' pathnames exceed maxpath on os/2

RESOLVED INVALID

Status

()

RESOLVED INVALID
12 years ago
11 years ago

People

(Reporter: ygk, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

12 years ago
User-Agent:       Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.8.1.5) Gecko/20070721 MultiZilla/1.8.3.2f eSeaMonkey/1.1.3
Build Identifier: Firefox 2.0.0.3 pre PW's custom build

Firefox does not check the path length when copying files to cache.trash result they are longer than os/2 can handle.

Reproducible: Always

Steps to Reproduce:
1.
2.
3.
(Reporter)

Comment 1

12 years ago
Created attachment 275205 [details]
Examples of excessive path length

Comment 2

12 years ago
Weird, I have never seen such paths inside the cache directory. I don't see any code that could create sub directories named \trash-10\cache\ and all cache dirs that I have seen only contain files that have 11char names, like F53E1272d01 (or other random names) and _CACHE_001_ or _CACHE_MAP_. To me that look like some other program was involved, too. Will watch a bit if I ever see something like this.

Comment 3

11 years ago
I haven't seen this since August nor have I found any code that could create something like this. Gregg, have you seen this again?
(Reporter)

Comment 4

11 years ago
It is still happening. I fixed FM/2 so it doesn't crash but I see the error message when I do a seek and scan on the firefox directory tree. I have 15 of these right now. Essentially the same as in comment #1. I haven't seen it in Seamonkey. I am currently running the following. I last had one of these generated on 12-24-07.

Addons

DOM Inspector 1.8.19
Fasterfox 2.0.0
MediaPlayer Conectivity 0.8.3
Mouse Gestures  1.5.2
NoScript 1.1.9.6
Table2Clipboard 0.0.3
Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.8.1.9) Gecko/20071103 PmWFx/2.0.0.9

Comment 5

11 years ago
OK, I have installed those add-ons now. Searching their sources I still didn't find anything that would cause filenames like the ones in attachment 275205 [details]. I also tried to "crash" Firefox a few times (just by killing it using different kill programs). That caused it to reinitialize / purge the disk cache but nothing else. Have to use it a bit more, I guess.

Do you actually remember any crashes that you could connect to the creation of those cache.trash dirs? If so, any chance to reproduce them? Are all the files named "8797859_mp0mmx*" or similar, and do you see any file in your program, plugins, and profile directories that contains these strings?
(Reporter)

Comment 6

11 years ago
Peter

I have looked at this more closely over the last couple of days. I am now guessing that the proxey server I use occassionally is creating this. It is for anonymous surfing and has some cashe features. I am seeing if  some of the features create this. The service is megaproxey. We are trying to determine how files like these can be generated in OS/2  to try to  "fix" fm/2 so it can't create them (it never has that we kown of and to delete them when found. I will let you know what we find out. This appears to be a DosMove call or perhaps a file save operation. I haope this is readable as I still have the one character wide dialog box on this machine. I have no idea what causes that problem either. Thanks

Comment 7

11 years ago
Gregg, did you find out more in the meantime? I would like to get this off the radar (best by closing it).
(Reporter)

Comment 8

11 years ago
Peter

I think this is related to megaproxy & mediaplayer connectivity. It appears to happen if I fail to delete downloads before exiting. I think it is a bug in OS/2 which allows a file to be copied/moved to a directory where the total length of the 2 names exceeds maxpath. I don't think this can be fixed in firefox except perhaps by a check of name length before any copy/move. In this case it may not even be firefox doing the copy/move. I am resolving this as invalid. I will reopen or file a new bug if I determine a way to approach fixing this in firefox itself. Thanks for looking at this

Gregg
Status: UNCONFIRMED → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.