[Jython-bugs] [ jython-Bugs-448398 ] open('test.txt','w').write('test') fails

[SourceForge.net <no...@so...>]

Bugs item #448398, was opened at 2001-08-06 12:48
Message generated for change (Settings changed) made by fwierzbicki
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112867&aid=448398&group_id=12867

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core
>Group: Deferred
Status: Open
Resolution: None
Priority: 5
Submitted By: Shae Erisson (eris)
Assigned to: Nobody/Anonymous (nobody)
Summary: open('test.txt','w').write('test') fails

Initial Comment:
Debian Linux, unstable
Blackdown JDK 1.3.1-1
Debian package of jython 2.1a2
open('test.txt','w').write('test') fails

in short, it seems you *must* call file.close or 
file.flush for jython to write a file to the disk.
even 
f = open('test.txt','w')
f.write('test')
import sys ; sys.exit()
will not write to the disk.

the file always ends up being empty unless flush() or 
close() is called.


----------------------------------------------------------------------

Comment By: Samuele Pedroni (pedronis)
Date: 2002-03-18 15:16

Message:
Logged In: YES 
user_id=61408

Oops, You're right. 

We probably should use a mixed
approach using both finalizers and a registration
mechanism.
If we use weak refs we should use:
System.gc()
System.runFinalization()

[Although from my experiments it seems that gc implies
runFinalization, but the doc does not confirm this]

in order to be sure that we do not have
cleared weak refs was referent finalizer will
not be called because we will just exit then soon.

----------------------------------------------------------------------

Comment By: Finn Bock (bckfnn)
Date: 2001-11-27 11:11

Message:
Logged In: YES 
user_id=4201

That would AFAICT require that finalizers should run at 
exit:
http://java.sun.com/products/jdk/1.2/docs/api/java/lang/Syst
em.html#runFinalizersOnExit(boolean)

That is not something that jython can/should enforce IMO. 
Adding a finalize method would still be an improvement in 
the cases where the file reference is dropped.

----------------------------------------------------------------------

Comment By: Samuele Pedroni (pedronis)
Date: 2001-11-23 16:26

Message:
Logged In: YES 
user_id=61408

Probably I'm missing something but cannot we use
the same techinique used by Sun for FileInput/OutputStream
in the java std library?
In the source for jdk 1.3 they both have a finalize
method that calls close when meaningful.

We could do the same for RFileWrapper.

I know that finalize should not be ab/used but...

----------------------------------------------------------------------

Comment By: Finn Bock (bckfnn)
Date: 2001-10-30 20:25

Message:
Logged In: YES 
user_id=4201

I haven't made up my mind about this yet. We could register 
open PyFile instances in a global collection and have some 
exit code that close all the files in the collection. An 
implementation would probably have to use weak references 
on java2. On java1 the GC'ing of files would then be 
disabled, which means that we must have a way of disabling 
the entire close-at-exit feature.

It feels like a lot of code with only a little gain but I'm 
not dismissing it completely because the current behaviour 
result in complete and silent loss of a lot of information.

Is it worth the trouble? Of so, what should the default be? 
Enabled close-at-exit for java2 and disabled for java1?


Note 1: I'm not even considering changing the behaviour for
    open('test.txt','w').write('test')
Code like that will still not close the file immediately.

Note 2: Supporting the buffer size argument could be 
another workaround.
At the moment python files are always buffered and while 
disabling
buffering could help for the example code, the two issues 
(close-at-exit
and buffering) are different problems.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112867&aid=448398&group_id=12867