Opera 9.01 deletes files in %TEMP%?
Mark V
FYI possible hazard....
I am uncertain of the details and conditions so far, but have
experienced the following here (W2K). Hence to preemptory WARNING
and request for others to observe there.
On Opera start all non +R files in %TEMP% are deleted!!!
When closed, Opera cannot be restarted at all (unless a different
opera.exe is run first).
While running the opera6.ini file on disk may be zero-length and when
closed, may not write the INI file.
I know this sounds alarmest, but I am alarmed!
I will be attempting to get more details etc.
--
Opera Win32 9.01-8552; W2K
For Windows I suggest using the "classic" installer package in all
cases </opinion>
Mark V
Cross-posted to: opera.tech
Follow-Ups set to: opera.tech
> Opera Win32 9.01-8552
>
> FYI possible hazard....
>
> I am uncertain of the details and conditions so far, but have
> experienced the following here (W2K). Hence to preemptory
> WARNING and request for others to observe there.
[ ]
Here is more... Any feedback welcomed.
- - - - - - - - - - -
Opera Win32 9.01-8552
W2K, SP4+; NTFS; Administrator auth.; Single-user install over 9.0-8501
No real-time "monitoring" processes are running.
Directory of C:\Program Files\Opera9
2006-07-27 18:26 3,204,096 Opera.dll
2006-07-27 18:26 79,360 Opera.exe
opera.exe is version 9.1.8552.0 (9.185520)
opera.dll is version 9.1.8552.0 (9.185520)
1)
On start deletes *all* found files possible in the
Temporary Downloads location
("Temporary Download Directory=")
This is outrageous of course and picture the user that has not selected
an exclusive "empty" location for this purpose. In other words as happened
here where the FQP to %temp% was used and files were destroyed.
Some lines from a FILEMON trace:
1 15:51:33 Opera.exe:288 IRP_MJ_CREATE C:\TEMP6\ SUCCESS Options: Open Directory Access: 00100001
2 15:51:33 Opera.exe:288 IRP_MJ_DIRECTORY_CONTROL C:\TEMP6\ SUCCESS FileBothDirectoryInformation: *
3 15:51:33 Opera.exe:288 IRP_MJ_DIRECTORY_CONTROL C:\TEMP6\ SUCCESS FileBothDirectoryInformation
4 15:51:33 Opera.exe:288 FASTIO_QUERY_OPEN C:\TEMP6\abbrev.html SUCCESS Attributes: A
5 15:51:33 Opera.exe:288 FASTIO_QUERY_OPEN C:\TEMP6\abbrev.html SUCCESS Attributes: A
6 15:51:33 Opera.exe:288 FASTIO_QUERY_OPEN C:\TEMP6\abbrev.html SUCCESS Attributes: A
7 15:51:33 Opera.exe:288 IRP_MJ_CREATE C:\TEMP6\abbrev.html SUCCESS Options: Open Access: 00010080
8 15:51:33 Opera.exe:288 IRP_MJ_QUERY_INFORMATION C:\TEMP6\abbrev.html SUCCESS FileAttributeTagInformation
9 15:51:33 Opera.exe:288 IRP_MJ_SET_INFORMATION C:\TEMP6\abbrev.html SUCCESS Delete
10 15:51:33 Opera.exe:288 IRP_MJ_CLEANUP C:\TEMP6\abbrev.html SUCCESS
11 15:51:33 System:8 IRP_MJ_CLOSE C:\temp6\abbrev.html SUCCESS
12 15:51:33 Opera.exe:288 IRP_MJ_CLOSE C:\TEMP6\abbrev.html SUCCESS
13 15:51:33 Opera.exe:288 FASTIO_QUERY_OPEN C:\TEMP6\abbrev.txt SUCCESS Attributes: A
14 15:51:33 Opera.exe:288 FASTIO_QUERY_OPEN C:\TEMP6\abbrev.txt SUCCESS Attributes: A
15 15:51:33 Opera.exe:288 FASTIO_QUERY_OPEN C:\TEMP6\abbrev.txt SUCCESS Attributes: A
16 15:51:33 Opera.exe:288 IRP_MJ_CREATE C:\TEMP6\abbrev.txt SUCCESS Options: Open Access: 00010080
17 15:51:33 Opera.exe:288 IRP_MJ_QUERY_INFORMATION C:\TEMP6\abbrev.txt SUCCESS FileAttributeTagInformation
18 15:51:33 Opera.exe:288 IRP_MJ_SET_INFORMATION C:\TEMP6\abbrev.txt SUCCESS Delete
19 15:51:33 Opera.exe:288 IRP_MJ_CLEANUP C:\TEMP6\abbrev.txt SUCCESS
20 15:51:33 System:8 IRP_MJ_CLOSE C:\temp6\abbrev.txt SUCCESS
21 15:51:33 Opera.exe:288 IRP_MJ_CLOSE C:\TEMP6\abbrev.txt SUCCESS
22 15:51:33 Opera.exe:288 FASTIO_QUERY_OPEN C:\TEMP6\ActiveSetup.txt SUCCESS Attributes: A
23 15:51:33 Opera.exe:288 FASTIO_QUERY_OPEN C:\TEMP6\ActiveSetup.txt SUCCESS Attributes: A
24 15:51:33 Opera.exe:288 FASTIO_QUERY_OPEN C:\TEMP6\ActiveSetup.txt SUCCESS Attributes: A
25 15:51:33 Opera.exe:288 IRP_MJ_CREATE C:\TEMP6\ActiveSetup.txt SUCCESS Options: Open Access: 00010080
26 15:51:33 Opera.exe:288 IRP_MJ_QUERY_INFORMATION C:\TEMP6\ActiveSetup.txt SUCCESS FileAttributeTagInformation
27 15:51:33 Opera.exe:288 IRP_MJ_SET_INFORMATION C:\TEMP6\ActiveSetup.txt SUCCESS Delete
28 15:51:33 Opera.exe:288 IRP_MJ_CLEANUP C:\TEMP6\ActiveSetup.txt SUCCESS
29 15:51:33 System:8 IRP_MJ_CLOSE C:\temp6\ActiveSetup.txt SUCCESS
30 15:51:33 Opera.exe:288 IRP_MJ_CLOSE C:\TEMP6\ActiveSetup.txt SUCCESS
31 15:51:33 Opera.exe:288 FASTIO_QUERY_OPEN C:\TEMP6\cryp_00.reg SUCCESS Attributes: A
32 15:51:33 Opera.exe:288 FASTIO_QUERY_OPEN C:\TEMP6\cryp_00.reg SUCCESS Attributes: A
33 15:51:33 Opera.exe:288 FASTIO_QUERY_OPEN C:\TEMP6\cryp_00.reg SUCCESS Attributes: A
34 15:51:33 Opera.exe:288 IRP_MJ_CREATE C:\TEMP6\cryp_00.reg SUCCESS Options: Open Access: 00010080
35 15:51:33 Opera.exe:288 IRP_MJ_QUERY_INFORMATION C:\TEMP6\cryp_00.reg SUCCESS FileAttributeTagInformation
36 15:51:33 Opera.exe:288 IRP_MJ_SET_INFORMATION C:\TEMP6\cryp_00.reg SUCCESS Delete
37 15:51:33 Opera.exe:288 IRP_MJ_CLEANUP C:\TEMP6\cryp_00.reg SUCCESS
38 15:51:33 Opera.exe:288 IRP_MJ_CLOSE C:\temp6\cryp_00.reg SUCCESS
39 15:51:33 Opera.exe:288 IRP_MJ_CLOSE C:\TEMP6\cryp_00.reg SUCCESS
40 15:51:33 Opera.exe:288 FASTIO_QUERY_OPEN C:\TEMP6\cyberterrorism_glossary.pdf SUCCESS Attributes: A
41 15:51:33 Opera.exe:288 FASTIO_QUERY_OPEN C:\TEMP6\cyberterrorism_glossary.pdf SUCCESS Attributes: A
42 15:51:33 Opera.exe:288 FASTIO_QUERY_OPEN C:\TEMP6\cyberterrorism_glossary.pdf SUCCESS Attributes: A
43 15:51:33 Opera.exe:288 IRP_MJ_CREATE C:\TEMP6\cyberterrorism_glossary.pdf SUCCESS Options: Open Access: 00010080
44 15:51:33 Opera.exe:288 IRP_MJ_QUERY_INFORMATION C:\TEMP6\cyberterrorism_glossary.pdf SUCCESS FileAttributeTagInformation
45 15:51:33 Opera.exe:288 IRP_MJ_SET_INFORMATION C:\TEMP6\cyberterrorism_glossary.pdf SUCCESS Delete
46 15:51:33 Opera.exe:288 IRP_MJ_CLEANUP C:\TEMP6\cyberterrorism_glossary.pdf SUCCESS
47 15:51:33 System:8 IRP_MJ_CLOSE C:\temp6\cyberterrorism_glossary.pdf SUCCESS
48 15:51:33 Opera.exe:288 IRP_MJ_CLOSE C:\TEMP6\cyberterrorism_glossary.pdf SUCCESS
49 15:51:33 Opera.exe:288 FASTIO_QUERY_OPEN C:\TEMP6\EXPLORER_Switches.TXT SUCCESS Attributes: A
50 15:51:33 Opera.exe:288 FASTIO_QUERY_OPEN C:\TEMP6\EXPLORER_Switches.TXT SUCCESS Attributes: A
51 15:51:33 Opera.exe:288 FASTIO_QUERY_OPEN C:\TEMP6\EXPLORER_Switches.TXT SUCCESS Attributes: A
52 15:51:33 Opera.exe:288 IRP_MJ_CREATE C:\TEMP6\EXPLORER_Switches.TXT SUCCESS Options: Open Access: 00010080
53 15:51:33 Opera.exe:288 IRP_MJ_QUERY_INFORMATION C:\TEMP6\EXPLORER_Switches.TXT SUCCESS FileAttributeTagInformation
54 15:51:33 Opera.exe:288 IRP_MJ_SET_INFORMATION C:\TEMP6\EXPLORER_Switches.TXT SUCCESS Delete
55 15:51:33 Opera.exe:288 IRP_MJ_CLEANUP C:\TEMP6\EXPLORER_Switches.TXT SUCCESS
56 15:51:33 System:8 IRP_MJ_CLOSE C:\temp6\EXPLORER_Switches.TXT SUCCESS
57 15:51:33 Opera.exe:288 IRP_MJ_CLOSE C:\TEMP6\EXPLORER_Switches.TXT SUCCESS
58 15:51:33 Opera.exe:288 FASTIO_QUERY_OPEN C:\TEMP6\for.txt SUCCESS Attributes: RA
59 15:51:33 Opera.exe:288 IRP_MJ_DIRECTORY_CONTROL C:\TEMP6\ NO MORE FILES FileBothDirectoryInformation
60 15:51:33 Opera.exe:288 IRP_MJ_CREATE C:\TEMP6\ SUCCESS Options: Open Directory Access: 00100001
61 15:51:33 Opera.exe:288 IRP_MJ_DIRECTORY_CONTROL C:\TEMP6\ SUCCESS FileBothDirectoryInformation: *
62 15:51:33 Opera.exe:288 IRP_MJ_DIRECTORY_CONTROL C:\TEMP6\ SUCCESS FileBothDirectoryInformation
63 15:51:33 Opera.exe:288 IRP_MJ_DIRECTORY_CONTROL C:\TEMP6\ NO MORE FILES FileBothDirectoryInformation
64 15:51:33 Opera.exe:288 IRP_MJ_CLEANUP C:\TEMP6\ SUCCESS
65 15:51:33 Opera.exe:288 IRP_MJ_CLOSE C:\TEMP6\ SUCCESS
66 15:51:33 Opera.exe:288 IRP_MJ_CLEANUP C:\TEMP6\ SUCCESS
67 15:51:33 Opera.exe:288 IRP_MJ_CLOSE C:\TEMP6\ SUCCESS
2)
On close, may leave <profile>\opera6.ini in a not accessible state. In
other words "Access Denied" but no open handles to the file and no file
access is possible. Opera 9.01-8552 will not start again under these conditions.
C:\Program Files\Opera9\Profile>copy opera6.ini nul
Access is denied.
C:\Program Files\Opera9\Profile>cacls opera6.ini
C:\Program Files\Opera9\Profile\opera6.ini
Access is denied.
C:\Program Files\Opera9\Profile>dir opera6.ini
Directory of C:\Program Files\Opera9\Profile
2006-08-03 15:23 17,715 opera6.ini
(The directory listing may alternatively show "zero bytes")
C:\>handle opera6.ini
Handle v3.2
No matching handles found.
C:\>pslist opera
PsList 1.26 - Process Information Lister
process opera was not found on computername
Running a R-O CHKDSK (or reboot) appears to clear the problem,
C:\Program Files\Opera9\Profile>chkdsk c:
The type of the file system is NTFS.
WARNING! F parameter not specified.
Running CHKDSK in read-only mode.
CHKDSK is verifying files (stage 1 of 3)...
File verification completed.
CHKDSK is verifying indexes (stage 2 of 3)...
Index verification completed.
CHKDSK is verifying security descriptors (stage 3 of 3)...
Security descriptor verification completed.
...
(And yes, my file system and disk is in good shape.)
After:
C:\Program Files\Opera9\Profile>copy opera6.ini nul
1 file(s) copied.
C:\Program Files\Opera9\Profile\opera6.ini BUILTIN\Users:R
BUILTIN\Power Users:C
BUILTIN\Administrators:F
NT AUTHORITY\SYSTEM:F
This is reminiscent of an earlier problem with closing files properly on
NTFS. I do not recall exactly but believe it was in an early version of 7.x
I feel BOTH these issues are CRITICAL and need immediate attention and
possibly even a public warning if it can be duplicated.
I am at your disposal for additional tests and information as required.
While #2 _could_ be system-specific, it appears that #1 is a general problem
in build 8552 Win32?
Any confirmation, feedback or suggestions welcomed.
John H Meyers
On Thu, 03 Aug 2006 14:05:50 -0500, Mark V wrote:
> Opera Win32 9.01-8552
Same here.
> FYI possible hazard....
>
> I am uncertain of the details and conditions so far, but have
> experienced the following here (W2K). Hence to preemptory WARNING
> and request for others to observe there.
>
> On Opera start all non +R files in %TEMP% are deleted!!!
My %TEMP% is C:\Documents and Settings\mylogin\Local Settings\Temp
and no such thing occurs on my own W2K with NTFS (where FWIW
I am logged in as a member of administrators group).
> When closed, Opera cannot be restarted at all
> (unless a different opera.exe is run first)
Not reproduced here, either;
it does take some time for my Opera to close, however,
due to "empty cache on exit"
> While running the opera6.ini file on disk may be zero-length
Not mine, in
C:\Documents and Settings\mylogin\Application Data\Opera\Opera\profile
> and when closed, may not write the INI file.
> I know this sounds alarmist, but I am alarmed!
> I will be attempting to get more details etc.
Is there any alarmingly psychotic anti-virus or similar software
also running? (or perhaps not running? :)
-[ ]-
Tim Altman
wrote:
>Opera Win32 9.01-8552
>
>FYI possible hazard....
>
>I am uncertain of the details and conditions so far, but have
>experienced the following here (W2K). Hence to preemptory WARNING
>and request for others to observe there.
>
>On Opera start all non +R files in %TEMP% are deleted!!!
>When closed, Opera cannot be restarted at all (unless a different
>opera.exe is run first).
>
>While running the opera6.ini file on disk may be zero-length and when
>closed, may not write the INI file.
>
>I know this sounds alarmest, but I am alarmed!
>I will be attempting to get more details etc.
Change your Temporary Download folder to something else, perhaps a
sub-folder of %TEMP%. Opera will wipe all files in the set Temporary
Download folder on start-up.
--
Tim Altman
Core QA
Opera Software
Remove NO SPAM from e-mail address to reply
Mark V
> On Thu, 03 Aug 2006 15:05:50 -0400, Mark V
> <notv...@nul.invalid> wrote:
>
>>Opera Win32 9.01-8552
>>
>>FYI possible hazard....
>>
>>I am uncertain of the details and conditions so far, but have
>>experienced the following here (W2K). Hence the preemptory
>>WARNING and request for others to observe there.
>>
>>On Opera start all non +R files in %TEMP% are deleted!!!
[ ]
Actually it is in the location defined by
"Temporary Download Directory="
> Change your Temporary Download folder to something else, perhaps
> a sub-folder of %TEMP%. Opera will wipe all files in the set
> Temporary Download folder on start-up.
Thanks so much for the rapid response and confirmation Tim. I have
already set it to an empty location. And test files there _are_
deleted (if not +R) on Opera startup.
YEOW! Such behavior ought to be called out in advance and well
documented and publicized. After all, letting the user blithely
set a path in which Opera will delete files not it's own is well,
inexcusable in my book.
Why did not OS utilize a DB file such as dcache4.url to have Opera
keep track of only those files it was once aware? Or fully
document and advertise the dangerous and unexpected behavior toward
any files in the specified location?
I realize you cannot answer all those on behalf of others. But I
hope you see the danger and can initiate some remedial or next-
version change or clarification.
So what does Opera 9.01 do/use when there is no path defined?
AFAICT "undefined" is the default installation state. On Win32
8552 anyway.
--
Opera Win32 9.01-8552; W2K
For Windows I suggest using the "classic" installer package in all
cases where feasible </opinion>
if
>
> Change your Temporary Download folder to something else, perhaps a
> sub-folder of %TEMP%. Opera will wipe all files in the set Temporary
> Download folder on start-up.
How do you set the temporary download folder? Is this different from the
normal download folder? Now I've heard of this problem I'm afraid to
install opera9 in case it autostarts after installation and deletes a bunch
of files before I get the chance to change any settings.
--
______________________________________________________
They also surf who only stand on waves.
______________________________________________________
Remco Lanting
> Tim Altman <do....@spam.me.invalid> wrote:
>>
>> Change your Temporary Download folder to something else, perhaps a
>> sub-folder of %TEMP%. Opera will wipe all files in the set Temporary
>> Download folder on start-up.
>
> How do you set the temporary download folder? Is this different from the
> normal download folder? Now I've heard of this problem I'm afraid to
> install opera9 in case it autostarts after installation and deletes a
> bunch
> of files before I get the chance to change any settings.
opera:config#UserPrefs|TemporaryDownloadDirectory (clickable in Opera)
Remco
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Mark V
> On Fri, 04 Aug 2006 18:49:24 +0200, if
> <nom...@nospam.org.invalid> wrote:
>
>> Tim Altman <do....@spam.me.invalid> wrote:
>>>
>>> Change your Temporary Download folder to something else,
>>> perhaps a sub-folder of %TEMP%. Opera will wipe all files in
>>> the set Temporary Download folder on start-up.
>>
>> How do you set the temporary download folder? Is this different
>> from the normal download folder? Now I've heard of this problem
>> I'm afraid to install opera9 in case it autostarts after
>> installation and deletes a bunch
>> of files before I get the chance to change any settings.
>
> opera:config#UserPrefs|TemporaryDownloadDirectory (clickable in
> Opera)
Correct. I had set that via opera:config only to find that the
location I set was getting "cleaned out" on every opera startup.
Any file not locked or set R-O would be silently deleted!
While this behavior might be okay in a controlled location such as
the default location used by Opera
<profile dir>\cache4\temporary_download\
it is Not Safe if the user is not aware of the unilateral and
silent behavior _and_ allows the user to select another path. One
that might contain important files. This situation is unacceptable
because the user is not directly apprised of a potentially
destructive condition.
I have changed it to an empty location of my choice now. Opera
will still delete any files found there if it can, but since I
named it \OperaTemporaryDownloadDirectory\ there is little chance
of me accidentally storing important data there by accident.
OS must change the method or provide interactive warning to be
"safe and sane" for this one.
John H Meyers
Given the surprising confirmed file deletion behavior,
I'm rather glad that it never occurred to me
to set my temporary download folder
to be my "Desktop" or "My Documents" !!!!!!!
Even if it were relegated to manually checking something
in Tools > "Delete private data,"
it would still be hazardous to allow it at all.
Don't other similar applications (even WinZip, say)
delete such temporary files (extracted files in WinZip's case)
only if and when the launched application terminates?
And in the case that the "higher" application terminates first, then
they just leave the extracted or downloaded temporary files alone,
exactly as they should, and they *never* dare to "wipe"
the entire destination folder on a new startup, fortunately.
-[ ]-
John H Meyers
would be to allow the user *no*choice*
of where to put the temporary files --
put them by default in or under the "cache4"
folder, for example, and then let the
"delete entire cache" function be re-christened
"delete entire cache and temporary download files."
-[ ]-
Mark V
> A much safer way to avoid this disaster
> would be to allow the user *no*choice*
> of where to put the temporary files --
> put them by default in or under the "cache4"
> folder, for example, and then let the
Yes! Hard-coded for "in" the CACHE4 location, which still allows the
user to specify "Cache Directory4=".
Or just plain _manage_ the files correctly. This is a bad bug in
terms of the logic applied to its design (or lack thereof).
> "delete entire cache" function be re-christened
> "delete entire cache and temporary download files."
If the storage location is controlled and dedicated it _might_ be
acceptable for Opera to "unilaterally delete contents on startup,
silently"... But that action/behavior is still very poor design in
my opinion.
nob...@nospam.com
<remco....@no.spam.at.gmail.please.com> wrote:
>On Fri, 04 Aug 2006 18:49:24 +0200, if <nom...@nospam.org.invalid> wrote:
>
>> Tim Altman <do....@spam.me.invalid> wrote:
>>>
>>> Change your Temporary Download folder to something else, perhaps a
>>> sub-folder of %TEMP%. Opera will wipe all files in the set Temporary
>>> Download folder on start-up.
>>
>> How do you set the temporary download folder? Is this different from the
>> normal download folder? Now I've heard of this problem I'm afraid to
>> install opera9 in case it autostarts after installation and deletes a
>> bunch
>> of files before I get the chance to change any settings.
>
>opera:config#UserPrefs|TemporaryDownloadDirectory (clickable in Opera)
>
>Remco
Oddly enough the syntax looks vaguely familiar, but I'm drawing a
blank on how that helps ;) Must be this headache. I was just
checking in and was happy they came out with an update. Then I read
some more. happy happy joy joy.
Maybe if they dropped the widgets and the bloatware, they could get
the basics straight ?
Sanford Aranoff
Tim Altman wrote:
> On Thu, 03 Aug 2006 15:05:50 -0400, Mark V <notv...@nul.invalid>
> wrote:
>
> >Opera Win32 9.01-8552
> >
> >FYI possible hazard....
> >
> >I am uncertain of the details and conditions so far, but have
> >experienced the following here (W2K). Hence to preemptory WARNING
> >and request for others to observe there.
> >
> >On Opera start all non +R files in %TEMP% are deleted!!!
> >When closed, Opera cannot be restarted at all (unless a different
> >
> Change your Temporary Download folder to something else, perhaps a
> sub-folder of %TEMP%. Opera will wipe all files in the set Temporary
> Download folder on start-up.
>
> --
> Tim Altman
> Core QA
> Opera Software
> Remove NO SPAM from e-mail address to reply
I do not have this problem.
How do I change the Temporary Download folder ?
nob...@nospam.com
>On Fri, 04 Aug 2006 19:02:10 +0200, "Remco Lanting"
><remco....@no.spam.at.gmail.please.com> wrote:
>>
>>opera:config#UserPrefs|TemporaryDownloadDirectory (clickable in Opera)
>>
>>Remco
>
>Oddly enough the syntax looks vaguely familiar, but I'm drawing a
>blank on how that helps ;) Must be this headache.
oh. you put opera:config in the address bar and you click on
UserPrefs on the resulting web page list, and then drop down to
TemporaryDownloadDirectory in the next list.
ok.
Why were you changing this ?
silly question.
Mark V
> In opera.general Tim Altman wrote:
>
>> On Thu, 03 Aug 2006 15:05:50 -0400, Mark V
>> <notv...@nul.invalid> wrote:
>>
>>>Opera Win32 9.01-8552
>>>
>>>FYI possible hazard....
>>>
>>>I am uncertain of the details and conditions so far, but have
>>>experienced the following here (W2K). Hence the preemptory
>>>WARNING and request for others to observe there.
>>>
>>>On Opera start all non +R files in %TEMP% are deleted!!!
> [ ]
>
> Actually it is in the location defined by
> "Temporary Download Directory="
>
>> Change your Temporary Download folder to something else,
>> perhaps a sub-folder of %TEMP%. Opera will wipe all files in
>> the set Temporary Download folder on start-up.
[ ]
> So what does Opera 9.01 do/use when there is no path defined?
> AFAICT "undefined" is the default installation state. On Win32
> 8552 anyway.
Opera calculates a default path beneath its user's Profile folder
and under the default "cache4" location and uses it. This is not
connected to the actual CACHE4 location if set by user. This is
not even a reflection of the INI setting of "nothing" such as
"Temporary Download Directory="
This brings me back to "opera:config does not accurately reflect
the INI contents in all cases."
If an INI entry is not present or set invalidly, opera:config must
display a visual indicator for "using a default or calculated
value" such that it is clear that this is not read from the INI.
Leon Fisk
Wrote in <eb0huv$htn$1...@news.opera.com>
Currently I use a special Cache location, actually it is
shared with the old 8.xx series in that directory structure.
However, the "temporary_download" is located under the
"9.xx\profile\cache4" directory. The cache4 directory in
this location is empty and not used. The cache4 directory
else ware being used doesn't have the "temporary_download"
directory attached to it.
Just a word of warning about this, that the
"temporary_download" doesn't automatically track the cache4
directory. You would have to make sure of this on your own
or at least be aware of it...
--
Leon Fisk
Grand Rapids MI
Remove no.spam for email
Opera 9.01-8552/PII/NT4sp6a
Glen
greatest* operating system, by making the default temp variable point to the DOS
directory , where all the system files resided. So, when Michael Polak developed
the Arachne DOS web browser years ago (he was unaware of this rather stupid
default), and had his browser setup delete all files in %temp%, guess what
happened?! Buh-bye system!
With precedents like that, one would think something like this would have been
avoided by Opera's developers.
...glen
"Mark V" <notv...@nul.invalid> wrote in message news:eaue8t$2pp$1...@news.opera.com...
Tim Altman
<ara...@analysis-knowledge.com> wrote:
>Tim Altman wrote:
>
>> On Thu, 03 Aug 2006 15:05:50 -0400, Mark V <notv...@nul.invalid>
>> wrote:
>>
>> >Opera Win32 9.01-8552
>> >
>> >FYI possible hazard....
>> >
>> >I am uncertain of the details and conditions so far, but have
>> >experienced the following here (W2K). Hence to preemptory WARNING
>> >and request for others to observe there.
>> >
>> >On Opera start all non +R files in %TEMP% are deleted!!!
>> >When closed, Opera cannot be restarted at all (unless a different
>> >
>
>> Change your Temporary Download folder to something else, perhaps a
>> sub-folder of %TEMP%. Opera will wipe all files in the set Temporary
>> Download folder on start-up.
>
>I do not have this problem.
You wouldn't if you hadn't changed the temporary download directory
location.
>How do I change the Temporary Download folder ?
See details in this thread.
Tim Altman
wrote:
>In opera.general Tim Altman wrote:
>
>> On Thu, 03 Aug 2006 15:05:50 -0400, Mark V
>> <notv...@nul.invalid> wrote:
>>
>>>Opera Win32 9.01-8552
>>>
>>>FYI possible hazard....
>>>
>>>I am uncertain of the details and conditions so far, but have
>>>experienced the following here (W2K). Hence the preemptory
>>>WARNING and request for others to observe there.
>>>
>>>On Opera start all non +R files in %TEMP% are deleted!!!
>[ ]
>
>Actually it is in the location defined by
> "Temporary Download Directory="
>
>> Change your Temporary Download folder to something else, perhaps
>> a sub-folder of %TEMP%. Opera will wipe all files in the set
>> Temporary Download folder on start-up.
[...]
>Why did not OS utilize a DB file such as dcache4.url to have Opera
>keep track of only those files it was once aware? Or fully
>document and advertise the dangerous and unexpected behavior toward
>any files in the specified location?
I believe this comes down to the INI setting being added after the
feature was originally added. Initially, we just created a directory
and wiped it on start-up, which is much faster than trying to figure
out that we just need to wipe all files in the directory anyway. When
the INI setting was added, this behavior didn't change to address the
new functionality. I'd say this is worthy of a bug report.
Tim Altman
wrote:
>Tim Altman <do....@spam.me.invalid> wrote:
>>
>> Change your Temporary Download folder to something else, perhaps a
>> sub-folder of %TEMP%. Opera will wipe all files in the set Temporary
>> Download folder on start-up.
>
>How do you set the temporary download folder?
It can only be changed by editing INI settings manually or via
opera:config.
>Is this different from the normal download folder?
Yes, quite different. The average user will never run into this
problem. It's only an issue for tweakers.
if
cache directory was used for the temporary storage of data.
--
______________________________________________________
Weinberg's First Law:
Progress is made on alternate Fridays.
______________________________________________________
Brixomatic
> >How do I change the Temporary Download folder ?
>
> See details in this thread.
Why doesn't opera create a subdir in %TEMP% by default?
%TEMP% on Windows is usually user specific (at least on my Windows 2000
box it is). This would also be a good place to place the cache-files.
When deletiong all its temp stuff it would only delete the stuff in its
subdir and everyone would be happy.
Greets,
-Wanja-
--
"Gewisse Schriftsteller sagen von ihren Werken immer: 'Mein Buch, mein
Kommentar, meine Geschichte'. [..] Es wäre besser, wenn sie sagten:
'unser Buch, unser Kommentar, unsere Geschichte'; wenn man bedenkt, dass
das Gute darin mehr von anderen ist als von ihnen." [Blaise Pascal]
John H Meyers
> What is the "Temporary Download folder" actually used for?
For the immediate pre-fetching of the file,
even before you decide where you'll actually save it?
-[ ]-
Nils
> Change your Temporary Download folder to something else, perhaps a
> sub-folder of %TEMP%. Opera will wipe all files in the set Temporary
> Download folder on start-up.
I was searching around for a solution to disable this "wipe-out" of
this folder on start-up. Is there any? If not I seriously hope there's
a "fix" in the next release.
--
Nils
Rijk van Geijtenbeek
Tim gave the only solution. Don't set your Temporary Download folder to a
folder with content that has to be kept. Maybe we should remove the option
to set the Temporary Download folder from opera:config?
--
Rijk
Opera Software ASA
QA etc
OmegaJunior
No... Opera should not delete anything that it didn't put in that folder
itself, and if it is something the user downloaded, the browser should not
delete it untill the user says so. The user expects his downloads to stay
put. The user expects his other files to stay put.
I hope Opera did not change their use of the download folder into a use of
the cache folders?
What Opera can do, is create their own special folder, so this unexpected
behaviour doesn't all of a sudden chase all Opera users into the claws of
Microsoft.
--
Yours,
ΩJr
Using Opera 9.01 build 8552 on Windows 2000 Server
Mark V
IMHO that directory should default to (and be created in (by
Opera)) the default or user-specified location of CACHE4. This is
the easiest and safest method I can imagine. And it most likely
serves the intention of the end-user if s/he has moved CACHE4. No
user option should be available in this case and no INI over-ride
should be available so long as the "unsafe and unwise" behavior is
retained.
But, the unilateral deletion of all files (or RMDIR of the
directory) is an unwise (at least) programming practice in any case
at all. Only by "internalizing and containing" such behavior can
the practice be even marginally justified. Opera Win32 9.01 does
do that by default (good), but the undocumented behavior along with
the user option to change location is the practical and operative
problem at present.
Cage the beast, or tame the beast. There is no other choice.
Ultimately this is deeper than just a UI change.
At present, and aside from future solutions, there is a _severe_
lack of documentation on this entirely unexpected and hazardous
behavior in the current released version and documentation!
There may be additional stability problems in this Opera version if
those files or the directory specified cannot be deleted on Opera
startup. (.tech thread, not pursued in depth here).
Rijk van Geijtenbeek
<omega...@spamremove.home.nl>:
..
>> Tim gave the only solution. Don't set your Temporary Download folder to
>> a folder with content that has to be kept. Maybe we should remove the
>> option to set the Temporary Download folder from opera:config?
>
> No... Opera should not delete anything that it didn't put in that folder
> itself, and if it is something the user downloaded, the browser should
> not delete it untill the user says so. The user expects his downloads to
> stay put. The user expects his other files to stay put.
It was not something the user downloaded, it was something the user
'opened' from the net. You get a choice between opening and downloading.
> I hope Opera did not change their use of the download folder into a use
> of the cache folders?
You have a choice now.
> What Opera can do, is create their own special folder, so this
> unexpected behaviour doesn't all of a sudden chase all Opera users into
> the claws of Microsoft.
That's what we did. See Tim's original explanation.
John H Meyers
> Tim gave the only solution. Don't set your Temporary Download folder
> to a folder with content that has to be kept. Maybe we should remove
> the option to set the Temporary Download folder from opera:config?
Great idea!
That would be a very significant improvement
against an otherwise hazardous situation,
like a guard rail to discourage an inexpert driver
from veering off a cliff :)
-[ ]-
John H Meyers
> The user expects his downloads to stay put.
Not these downloads, actually, because this place was meant
to be only for files which are *supposed* to be deleted after use
(such as installers for which you choose "open" rather than "save").
However, it is exactly this user confusion which can readily lead someone
to re-point a path which was intially a safe "throw-away" (buried under cache)
to a more permanent place, confusing a *temporary* download folder
with a *default* download folder
(you naturally expect the latter to be permanent,
but the former need not be).
If Opera had more carefully monitored its temporary downloads,
deleting each one only after its specific use had just completed
(or via some other bookkeeping system, such as recording the file names
downloaded in the previous session, for removal at the start of the next),
then this would have been much safer than the "wipe clean on startup"
cavalier approach, at the expense of sometimes leaving a few files
undeleted after crashes, say (or after closing Opera before running
the downloaded installer, which might sometimes be Opera's own installer,
and thus even require Opera to first be closed).
Opera has thus "fixed" a potential minor occasional
"disk space leak (waste)" problem, at the expense
of risking a greater catastrophe, should the user fail
to grasp the full import of moving the default location.
It's nice of Opera to avoid "littering" the hard disk with junk,
as do so many inconsiderate applications, but its current method
is a dangerous one, because it lets the user modify it easily,
which is like letting a safety cage be removed from a saw blade:)
-[ ]-
Brian L Johnson
> Tim gave the only solution. Don't set your Temporary Download folder to a
> folder with content that has to be kept.
>
Right now, my wife is one p*ssed-off lady.
Yesterday afternoon, she emailed herself a Powerpoint presentation from
her place of work so that she could complete it at home.
She gets home, opens her email in Opera, opens and alters the attached
PPT and *saves it*.
This morning, she opens her email again to check it and send it back to
work and...
...it's the same, unchanged PPT that she sent herself yesterday!
She's now stormed off to work and I've just been investigating what
happened.
And this is what I find:
1. Last night, she looked at her email and opened the attached PPT file.
2. M2 drops a copy of the PPT into TemporaryDownloads and then passes
that to Powerpoint for her to work in.
3. She spends an hour or so altering it in Powerpoint.
4. She exits from Powerpoint and it asks her "Do you want to save
this?" She answers Yes.
5. Powerpoint saves the alterations and closes.
6. Back in Opera, just to check, she opens the attachment again and
verifies that it's the altered version. It is.
Let me rephrase that.
THE ALTERED VERSION IS NOW APPARENTLY ATTACHED TO THE EMAIL!
7. She closes Opera.
8. Opera now silently deletes the altered attachment.
9. Next morning: one seriously p*ssed-off wife.
10. So... a question: Do I tell her what happened or do I just quietly
switch her back to a reliable email program?
--
-blj-
John H Meyers
On Tue, 22 Aug 2006 07:10:28 -0500, Rijk wrote:
> Maybe we should remove the option
> to set the Temporary Download folder from opera:config?
As someone else may have noted, any moving of the cache
(if temp. downloads are under it) should also move the
temp downloads along with it -- is this already a fact,
or should it be added to the "must do" list for this option,
independent of the above?
-[ ]-
John H Meyers
Follow-up to opera.mail+news]
On Wed, 23 Aug 2006 04:03:46 -0500, Brian L Johnson wrote:
[email attachments apparently extract to "temp downloads" folder,
from where they are opened in appropriate application,
but suppose that app is an editor, any saved results of editing
*appear* to still be attached during *current* opera session,
but are thrown away when Opera next closes/reopens, after which
an unedited original attachment re-extracts "over" edited version]
Uh-oh -- another, previously unencountered usage of "temp downloads"
folder (as a "temporary attachment extraction" folder too?),
and an apparent additional mistake in app design.
The suggestion to "fix" by not letting user modify default location
would do nothing to fix this additional problem
(the original problem was Opera's wiping other, unrelated files,
which Opera had actually never stored itself,
from a user-altered location which Opera thinks is all its own).
-[ ]-
Rijk van Geijtenbeek
<jhme...@nomail.invalid>:
>
> Opera has thus "fixed" a potential minor occasional
> "disk space leak (waste)" problem, at the expense
> of risking a greater catastrophe, should the user fail
> to grasp the full import of moving the default location.
I really don't think this will be a common issue [1] - how many people
will try to edit the storage location for *temporary* downloads without
realising this is about temporary stuff? The %temp% directory mentioned
was a logical choice for such stuff, and it is also directory meant for
'deletable' stuff so the harm is limited I hope.
I'm actually way more worried about the other scenario you describe, with
the powerpoint file, because it involves no tweaking at all... I tried to
replicate it with an attached XLS file, and could confirm the issue
partly. If you switch to another mail and then select the message again,
the original attachment will be shown. But that will of course only help
in shaping the mental model the user has of what 'Open' does, it would
still mean a lost hour. Maybe we should lock the file so other apps can't
save over it. That way the app would always show the 'pick a name' dialog.
If the user then uses the existing directory, there is of course still the
same problem, so I think we need to improve this anyway.
[1] Not saying it is not an issue - Opera should either monitor and only
delete its own files, or not allow such customization.
Charles Lindsey
>1. Last night, she looked at her email and opened the attached PPT file.
>2. M2 drops a copy of the PPT into TemporaryDownloads and then passes
>that to Powerpoint for her to work in.
>3. She spends an hour or so altering it in Powerpoint.
>4. She exits from Powerpoint and it asks her "Do you want to save
>this?" She answers Yes.
>5. Powerpoint saves the alterations and closes.
>6. Back in Opera, just to check, she opens the attachment again and
>verifies that it's the altered version. It is.
And that is where it went wrong.
It should always be *totally*impossible* to alter anything that is in your
inbox, and if Opera can do this, or even give the appearance of having
done this, then it is a serious BUG.
--
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133 Web: http://www.cs.man.ac.uk/~chl
Email: c...@clerew.man.ac.uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
Brian L Johnson
> It should always be *totally*impossible* to alter anything that is in your
> inbox,
Why?
<snip>
--
-blj-
John H Meyers
Since I use Opera's "M2" client only for newsgroups,
I can not experiment with receiving attachments,
but am relying on the claims made in this thread.
On Thu, 24 Aug 2006 09:49:36 -0500, Charles Lindsey wrote:
> It should always be *totally*impossible* to alter anything
> that is in your inbox, and if Opera can do this,
> or even give the appearance of having done this,
> then it is a serious BUG.
It all depends on the general design of the email application,
and may be entirely reasonable. Some applications (e.g. OE)
only extract attachments on demand, and then store these
wherever you want (so you can of course edit your extracted copy,
without OE ever bothering with it again, or you can also
extract a fresh, new, unaltered original); others, like Eudora,
extract attachments immediately upon downloading from POP server,
placing them in a designated (and never purged) folder,
where you can then of course *permanently* edit them, if you like.
If the previous post is correct, then it would seem that Opera
might extract attachments only into a *temporary* directory,
allow you to edit them (as does Eudora),
but then *delete* them at the end of every session;
such a design is certainly a bit far out,
and obviously invites trouble,
just as does the basic idea of globally purging
any user-specifiable temporary downloads folder,
even if it were *intended* only for temporary downloads.
For the temporary downloads issue only,
another concept to consider would be to let the user
choose where to put it, but then at the start of every session,
create a brand new (randomly named) folder *under*
the designated original folder location, finally purging
that entire *guaranteed*new* folder at session end
(something vaguely like this seems to be performed
by some of the new widgets, particularly the RSS news readers).
-[ ]-
John H Meyers
I forgot to mention that it is a very convenient deliberate feature
of Eudora that you can even edit *incoming* message subject lines
and/or even the text in the *body* of incoming messages;
I utilize this feature all the time, to supply or clarify
missing or non-descriptive "subject" lines,
to annotate or to fix spellings, etc.
-[ ]-
Charles Lindsey
>On Thu, 24 Aug 2006 09:49:36 -0500, Charles Lindsey wrote:
>> It should always be *totally*impossible* to alter anything
>> that is in your inbox, and if Opera can do this,
>> or even give the appearance of having done this,
>> then it is a serious BUG.
>It all depends on the general design of the email application,
>and may be entirely reasonable. Some applications (e.g. OE)
>only extract attachments on demand, and then store these
>wherever you want (so you can of course edit your extracted copy,
>without OE ever bothering with it again, or you can also
>extract a fresh, new, unaltered original);
Yes, that's fine.
>... others, like Eudora,
>extract attachments immediately upon downloading from POP server,
>placing them in a designated (and never purged) folder,
>where you can then of course *permanently* edit them, if you like.
But that seems dangerous. If you go back to reread the original email,
then you should see it exactly as it originally arrived. So if you had
hacked about with an attachment (and maybe even accidentally deleted it),
then you can go back and start over.
>If the previous post is correct, then it would seem that Opera
>might extract attachments only into a *temporary* directory,
>allow you to edit them (as does Eudora),
>but then *delete* them at the end of every session;
On thinking abut this further, what Opera SHOULD have done is to have made
the copy in the temporqry directory Read-Only. Then any editor (often a
plug-in, as in the original example) will either refuse to edit it until
you have made a copy, or it will at least warn you when you try to Save,
so you know to Save it to a new file. That would have been sufficient to
prevent the loss of an hour's work that was reported.
Matthew Winn
> Charles Lindsey wrote
>
> > It should always be *totally*impossible* to alter anything that is in your
> > inbox,
>
> Why?
I can think of two situations when it would be very useful to be able
to edit received messages, both of which I encounter regularly:
(1) When you want to keep one part of a long message for future
reference but don't want to store the rest of the message because
it'll take up more room and make it harder to find the useful part.
(2) When someone sends you a message that you want to keep, but the
subject of the message is blank, meaningless, out of date or
misleading in some other respect.
--
Matthew Winn
[If replying by email remove the "r" from "urk"]
Brian L Johnson
> On thinking abut this further, what Opera SHOULD have done is to have made
> the copy in the temporqry directory Read-Only. Then any editor (often a
> plug-in, as in the original example) will either refuse to edit it until
> you have made a copy, or it will at least warn you when you try to Save,
> so you know to Save it to a new file. That would have been sufficient to
> prevent the loss of an hour's work that was reported.
>
Sadly, this actually may be an poor solution.
What would happen is that you'd open the attachment in the associated
application and, when you tried to save a copy, the SaveAs dialog would
normally open up in the location where the original ReadOnly file was
located -- that is, in temporary_downloads\ .
Where Opera would promptly delete the copy upon next re-start. :(
So, the user would have to navigate away from the proffered folder on
every single occasion that they opened an attachment. Bad.
A somewhat better solution is for Opera to drop a copy of the attachment
in the user-specified download location and then offer that to the
associated application.
(The only problem with that is that some users will complain that Opera
is unnecessarily saving attachments on their hard drive. My view is
that if you want to open and change an attachment, you want it saved on
your hard disc, so stop moaning.)
--
-blj-
John H Meyers
On Fri, 25 Aug 2006 06:11:56 -0500, Charles Lindsey wrote:
> [Eudora] seems dangerous. If you go back to reread the original email,
> then you should see it exactly as it originally arrived. So if you had
> hacked about with an attachment (and maybe even accidentally deleted it),
> then you can go back and start over.
No email client can insure you against deleting original messages,
for example, in which case (after you've emptied trash),
you've lost the attachments too -- except that in Eudora,
you have the choice whether to "delete attachments when
[original message is] emptied from trash," so that in some cases,
Eudora protects you from the hazard of losing attachments
when you inadvertently delete an original message,
whereas OE protects you from losing attachments
when you inadvertently delete only the attachment :)
It's simply that different overall application designs
each have their own set of relative virtues vs. potential pitfalls,
and I can't see any universally objective way to compare them.
> On thinking abut this further, what Opera SHOULD have done is to have made
> the copy in the temporary directory Read-Only. Then any editor (often a
> plug-in, as in the original example) will either refuse to edit it until
> you have made a copy, or it will at least warn you when you try to Save,
> so you know to Save it to a new file. That would have been sufficient to
> prevent the loss of an hour's work that was reported.
Not necessarily: what if the user simply picked a new "simple name"
in the "Save as" dialog? -- if the newly *copied* object were still
in the same "temporary downloads" directory as the original,
and if Opera "wipes" that entire directory anyway,
then there goes all that editing work down the very same drain!
We always seem to end up facing the same sad fact
that the decision to indiscriminately wipe any entire directory
can always come back to haunt us,
even though many ideas for dodging one or another particular
avenue for getting in trouble may eliminate just that one sand trap,
while still leaving others exposed that are just as bad.
-[ ]-
John H Meyers
On Fri, 25 Aug 2006 07:42:18 -0500, Matthew Winn wrote:
> I can think of two situations when it would be very useful to be able
> to edit received messages, both of which I encounter regularly:
> (1) When you want to keep one part of a long message for future
> reference but don't want to store the rest of the message because
> it'll take up more room and make it harder to find the useful part.
So glad you mentioned that -- people often reply with one sentence
or paragraph, mixed with ten-pages of message history,
which I very frequently edit out,
so that my personal mail backup doesn't grow so huge.
It was extremely clever of Gmail to work around this common practice,
at least in the web display of messages if not their storage,
through their use of "Show/hide quoted text" links
(this would be a fine new idea for local mail clients as well).
> (2) When someone sends you a message that you want to keep,
> but the subject of the message is blank, meaningless,
> out of date or misleading in some other respect.
Eudora comes to the rescue very cleverly here, letting you edit
a *copy* of the "Subject" which resides in the mailbox *index*,
rather than in the original "mailbox format" file itself.
-[ ]-
Charles Lindsey
>Charles Lindsey wrote
>> On thinking abut this further, what Opera SHOULD have done is to have made
>> the copy in the temporqry directory Read-Only. Then any editor (often a
>> plug-in, as in the original example) will either refuse to edit it until
>> you have made a copy, or it will at least warn you when you try to Save,
>> so you know to Save it to a new file. That would have been sufficient to
>> prevent the loss of an hour's work that was reported.
>>
>Sadly, this actually may be an poor solution.
>What would happen is that you'd open the attachment in the associated
>application and, when you tried to save a copy, the SaveAs dialog would
>normally open up in the location where the original ReadOnly file was
>located -- that is, in temporary_downloads\ .
>Where Opera would promptly delete the copy upon next re-start. :(
Yes, to make it utterly foolproof, Opera would have to make that whole
directory read-only, except for the few milliseconds when it was actually
trying to write a new file to it.
>So, the user would have to navigate away from the proffered folder on
>every single occasion that they opened an attachment. Bad.
Only if they intended to edit the file, which is not the usual case.
>A somewhat better solution is for Opera to drop a copy of the attachment
>in the user-specified download location and then offer that to the
>associated application.
Yes, but you don't want to force the user to specify a download location
in the common case where he only wants to open the attachment in order
to view it. And he dosn't want his disk cluttered up with a copy of every
attachment he has ever viewed (which is why Opera sensibly empties the
temporary directory upon exit - you can't have your cake and eat it).
Rijk van Geijtenbeek
<c...@clerew.man.ac.uk>:
..
> Yes, but you don't want to force the user to specify a download location
> in the common case where he only wants to open the attachment in order
> to view it. And he dosn't want his disk cluttered up with a copy of every
> attachment he has ever viewed (which is why Opera sensibly empties the
> temporary directory upon exit - you can't have your cake and eat it).
Obviously opinions differ on whether to have cake or eat it - I want it
both as well :)
I do remember I had to manually scrub some sub-sub directories of my
TheBat! installation (mail client), at that time I didn't have that much
hard disk space to waste. Was quite annoying as there are so many rubbish
attachments (PGP signatures, docs that where shuttled around with little
corrections each time) - but good in that I could remove big attachments
without deleting a message.
Brian L Johnson
> Yes, to make it utterly foolproof, Opera would have to make that whole
> directory read-only, except for the few milliseconds when it was actually
> trying to write a new file to it.
>
Not necessarily, as I've said elsewhere, when Opera closes, it needs
only look in the user-specified downloads folder to check whether any
Opened... attachments have (a) been changed (and, hence, cannot be auto-
deleted), or (b) have NOT been changed (and, hence, *can* be auto-
deleted).
Job done. ')
--
-blj-
John H Meyers
> he dosn't want his disk cluttered up with a copy of every
> attachment he has ever viewed (which is why Opera sensibly
> empties the temporary directory upon exit -
> you can't have your cake and eat it).
If the attachments remain encoded *within* each message,
then your disk is "littered" anyway, with a copy
(actually even an *expanded* copy) of every attachment
you have ever *received* (until you delete its original message).
Eudora's design separates attachments upon receipt;
then opening attachments does not create any extra copy,
the fate of original messages vs. attachments can be
either linked or separated, and one can delete unwanted
attachments without deleting messages they came with
(and vice versa) -- all very appealing to me.
Blanket directory wiping always comes with serious
pitfalls and hazards (like wiping edited files that
were intended to be saved, even if the edited copy
was given a new name); the only risk in a system
which monitors and manages much more carefully
is that some few disposable files will survive
after crashes or main application terminations
before the use of the temp file has ended, and
I'd much rather pay the price of a little Spring cleaning
now and then than the price of irretrievably lost files.
Having extracted email attachments share a "wipe clean"
temporary downloads folder strikes me as a reckless
invitation to many disaster scenarios -- unless we
have "thought of everything" that could possibly
be done, our ideas to prevent the simpler goofs
are fraught with peril of other loopholes
which we didn't yet think of,
and I don't like anything which can't be
*proven*infallible*, rather than just blindly assumed to be,
after only superficial thought.
-[ ]-
John H Meyers
> when Opera closes, it needs only look in the user-specified downloads folder
> to check whether any Opened... attachments have (a) been changed
Now all we need is an iron-clad test for that :)
[have you thought about a zip file, say,
and whether its files have been
*extracted* into the same folder or not? Etc.]
Plus not wiping the *entire* folder anyway,
which renders all other fussing a bit moot.
As Grandma used to say:
"Don't throw out the baby with the bath water"
-[ ]-
Charles Lindsey
>On Mon, 28 Aug 2006 10:30:09 -0500:
>> he dosn't want his disk cluttered up with a copy of every
>> attachment he has ever viewed (which is why Opera sensibly
>> empties the temporary directory upon exit -
>> you can't have your cake and eat it).
>If the attachments remain encoded *within* each message,
>then your disk is "littered" anyway, with a copy
>(actually even an *expanded* copy) of every attachment
>you have ever *received* (until you delete its original message).
Not so, because I delete messages I no longer require, and clear the Trash
periodically.
But if every attachment opened remained in the %TEMP% directory
indefinitely, that would grow without limit.
If you want to edit an attachment, then copy it to a file. If you just
want to look at it (and it will usually turn out to be of no interest),
then the browser is under no obligation to retain it.