Closed Bug 312265 Opened 18 years ago Closed 11 years ago

Freeze or generic fails when a Windows reserved name (e.g. LPT1,PRN,CON, AUX,...) is used (for saved searche folders, subfolders, ...)

Categories

(Thunderbird :: Mail Window Front End, defect)

x86
Windows XP
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: sugar.waffle, Unassigned)

References

(Depends on 1 open bug, Blocks 1 open bug)

Details

Attachments

(1 file)

Reproducible: Always

Steps to Reproduce:
1.Open File -> New -> Saved Search
2.PRN is input to the name field.
3.The search condition is input and the OK button is pushed. 

Actual Results:
hung up.
(talkback do not start.)


Windows XP SP1
version 1.5 Beta 2 (20051011)
Bug 311339 is "CON" of usual folder name case. 
Summary: When a special name(LPT1,PRN) is used with "Saved Search Folder", it is hung up. → When a special name(LPT1,PRN) is used with "Saved Search Folder", it is hung up.
Blocks: 370090
Possibly crash when search folder such as con/prn, because Bug 286523 occurs at same time.
Depends on: 311339
I would consider duplicating
bug 358208
bug 286523
for this one
(bug 358208 is a dupe of bug 286523 clearly)
though 286523 is more active ..

I reproduced 358208 in c3 with description and attach.
As I commented on bug 358208, I get the identical(really in every detail) behavior for "/" and "LPT1" on saved search names in TB 2.0.0.14 and 3.0apre (with that description ..)

Also bug 286523#c8 states that for virtual folders there is use of older code than for normal folders, which may lead to a solution.

I consider getting here or there all description and attach after dupes are set
correction on comment #3

bug 358208 has same problem as this one and should dupe for this, adding // to the "special names" list

the rest of the comment is not very accurate, bug 286523 not same ..
About what  I said in comment #3 and comment #4 and bug 358208 :
-these LPT1, PRN, // something,  are case of hang in 2.0.0.14 
-in TB3.0a1pre I was also reproducing it in a more subtle manner

In 3.0a1rc1 ?
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9pre) Gecko/2008050715 Lightning/0.6a1 Thunderbird/3.0a1 ID:2008050715
I can apparently use LPT1 and PRN as names of saved searches without hang, but no correct results. I wonder if there was a patch or something in test/build regarding TB3.0a1 that solved this. 

Not the case for //something names in bug 358208, which makes me not recommend duping anymore.

But I don't consider solved TB3.0a1rc1:
Still, no hang but not being able to use PRN, LPT1 saved searches. I tried also COM1, no result, and COM3 hang!

Description actions with prn and something//:
reproducible :always

1.-save search "gigel//"
-save search "PRN"
-ok -nothing
-ok again -"a folder w t name already exists .."
-collapse/uncollapse acc to refresh tree
-!another "some//" appears with 2 subf named same:
gigel// -original
gigel// +??
 gigel//
   gigel//
!!
on rclick/properties on "PRN" it does allow selecting other folders but no name is shown (nor can be entered)

2. close app /restart
!-no "PRN" saved search !
-no "gigel//" duplicates ..
-delete "gigel//" to see if has influence..
-create again "PRN"/ok/ok/"a folder ..." alert
-refresh acc tree
! PRN is there, v// with 2 subf appear!

3. close/restart app
!-no PRN
!!!- "gigel//" is back there (no ghost, can select properties ..)
-in profile, folder and msf are called "gigel9d4b2d35"
-in TB, delete gigel// 

4. restart app
-save search PRN/ok (no reaction)cancel
-refresh acc -is there
-not in profile folder!
-properties again not presenting a name (blanc field)

stop

!!OK, this properties window with no name and no criteria may be realted to bug 422450 capture attachment id=308891
Assignee: mscott → nobody
Component: General → Mail Window Front End
QA Contact: general → front-end
Version: 1.5 → unspecified
This completes comment 5

The ssearch is rather temporary or ghost, no profile folder/msf equivalent and dissapear on restart app. The property panel has no name and no criteria

May be related to bug 422450, see capture there

Also changed to "front-end" and version "all" as 
-originally posted for tb1.5
-I tried TB2 and Tb3trunk
so no hang? (if it is we need to adjust sev+keyword)
is bug 311339 behaving the same?
(In reply to comment #7)
> so no hang? (if it is we need to adjust sev+keyword)
Not hang

> is bug 311339 behaving the same?
Yes it is.

But I see that when create a "saved search" (or "subfolder"), open "New saved search folder" window, fill "PRN" as name and click OK button not close the window. After I click on "Cancel" button, folderpane not is update with new saved search folder (or subfolder): I do goto next Folder view and return to previous for update fgolder pane  (bug already filled I remember... or not?).
feel free to improve summary further
Summary: When a special name(LPT1,PRN) is used with "Saved Search Folder", it is hung up. → not nice when a special name(LPT1,PRN) is used with "Saved Search Folder"
Summary: not nice when a special name(LPT1,PRN) is used with "Saved Search Folder" → Not nice when a special name(LPT1,PRN,CON, AUX, and others Windows reserved name) is used with saved searche folders or subfolders
Summary: Not nice when a special name(LPT1,PRN,CON, AUX, and others Windows reserved name) is used with saved searche folders or subfolders → Freeze or generic fails when a Windows reserved name (e.g. LPT1,PRN,CON, AUX,...) is used (for saved searche folders, subfolders, ...)
Create an IMAP folder named PRN (on a system that is not Windows). Then start the Thunderbird under Windows. The first seconds it runs normally - then it stucks for several minutes.

After a while you can continue working for several minutes then it hungs again.

The problem is the filename. For every folder name a file is created - and you can't use PRN as filename under Windows.

The system should look into the list of forbidden filenames to prevent this problem:
http://msdn.microsoft.com/en-us/library/dd745740%28v=bts.10%29.aspx
Freeze doesn't seem to occur any more. Current phenomenon looks bug 817681.
Closing as WORKSFORME, because freeze is resolved by unknown patch.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.