Hi all,
Ruby 1.6.8 and 1.8.0p2
Solaris 9
When I call PStore.new multiple times, in some cases there are temp
files left over on my filesystem.
Begin code sample - seems to work ok.
require “pstore”
store = PStore.new(“temp.store”)
store.transaction{
store[“foo”] = “Hello World!”
}
store = PStore.new(“temp.store”)
store.transaction{
p store[“foo”] # -> “Hello World!”
}
End code sample
Using the above code, I end up with “temp.store” and “temp.store~” on my
filesystem. I tried rescuing the second call to PStore.new as well just
in case, but I didn’t catch any Exceptions.
So, really I have three questions: Why is it creating a tempfile?
Assuming it’s supposed to create a tempfile, why isn’t it removed when
the program is complete? Lastly, are there any potential problems
associated with the tempfile or can I safely ignore this issue?
Regards,
Dan
···
–
p
[“010100101010111011001110001011100000010010000010011101101111011000101110000101101010011001001110000001000100101010101110010001101001111000000100000100101000011011000110110101101010011001001110”].pack(“b*”)
Hi,
So, really I have three questions: Why is it creating a tempfile?
Assuming it’s supposed to create a tempfile, why isn’t it removed when
the program is complete? Lastly, are there any potential problems
associated with the tempfile or can I safely ignore this issue?
q1: Why is it creating a tempfile?
a1: It’s not a tempfile, it’s a backup file.
q2: Why isn’t it removed when the program is complete?
a2: You can’t remove a backup file. If you do, it’s no longer a backup. 
q3: are there any potential problems associated with the tempfile or
can I safely ignore this issue?
a3: You can ignore it, until you need backup.
matz.
···
In message “PStore and tempfiles - bug?” on 03/05/08, Daniel Berger djberge@qwest.com writes:
matz@ruby-lang.org (Yukihiro Matsumoto) writes:
···
In message “PStore and tempfiles - bug?” > on 03/05/08, Daniel Berger djberge@qwest.com writes:
So, really I have three questions: Why is it creating a tempfile?
Assuming it’s supposed to create a tempfile, why isn’t it removed when
the program is complete? Lastly, are there any potential problems
associated with the tempfile or can I safely ignore this issue?
q1: Why is it creating a tempfile?
a1: It’s not a tempfile, it’s a backup file.
q2: Why isn’t it removed when the program is complete?
a2: You can’t remove a backup file. If you do, it’s no longer a backup. 
q3: are there any potential problems associated with the tempfile or
can I safely ignore this issue?
a3: You can ignore it, until you need backup.
Hmm…Where can I read more about PStore?
Karsten
q1: Why is it creating a tempfile?
a1: It’s not a tempfile, it’s a backup file.
I don’t need a backup. It should be possible to turn this off.
But it looks to me like it’s not a backup. It looks like the file is
created in case there is an exception thrown during file.truncate();
if this happens, the backup is renamed (not copied) over the original.
q2: Why isn’t it removed when the program is complete?
a2: You can’t remove a backup file. If you do, it’s no longer a backup. 
There is code in pstore.rb to remove the backup file:
if @abort and !orig
File.unlink(@filename)
end
But orig is never false, so the backup never gets removed. I don’t know
what the author’s intention was, but I’m sure unreachable code was not
it.
q3: are there any potential problems associated with the tempfile or
can I safely ignore this issue?
a3: You can ignore it, until you need backup.
I agree, but note that the backup file disappears if writing to the file
fails. You cannot depend on its existence.
Paul
···
On Thu, May 08, 2003 at 10:52:46AM +0900, Yukihiro Matsumoto wrote:
Hi,
I don’t need a backup. It should be possible to turn this off.
Why? You don’t make mistake? I always do.
q2: Why isn’t it removed when the program is complete?
a2: You can’t remove a backup file. If you do, it’s no longer a backup. 
There is code in pstore.rb to remove the backup file:
if @abort and !orig
File.unlink(@filename)
end
But orig is never false, so the backup never gets removed. I don’t know
what the author’s intention was, but I’m sure unreachable code was not
it.
It’s for the case:
- there’s not foo, but foo~.
- transaction is aborted.
This is very rare case, but not impossible. I wanted to remove
unrelated files which look like backup files.
q3: are there any potential problems associated with the tempfile or
can I safely ignore this issue?
a3: You can ignore it, until you need backup.
I agree, but note that the backup file disappears if writing to the file
fails. You cannot depend on its existence.
Hmm, I assume the author (me) wanted back files to exist when
- the pstore file had existed before the transaction
- and pstore file had changed by the transaction
So I thought it’s natural to restore original file by renaming it from
the backup. If there’s no backup files, we can assume no modification
has done by the last transaction. Am I wrong somewhere?
matz.
···
In message “Re: PStore and tempfiles - bug?” on 03/05/08, Paul Brannan pbrannan@atdesk.com writes:
matz@ruby-lang.org (Yukihiro Matsumoto) writes:
Hmm…Where can I read more about PStore?
More than Pickaxe? Not in English, sorry. You can ask here if you
have questions.
So it is documented in the Pickaxe? Hmm…I will have to look again -
it’s not in the index…
Karsten
I don’t need a backup. It should be possible to turn this off.
Why? You don’t make mistake? I always do.
I’m not so sure that it’s the idea of making a mistake, it’s the idea of not
being able to “live dangerously” if one wants to.
It’s for the case:
- there’s not foo, but foo~.
- transaction is aborted.
This is very rare case, but not impossible. I wanted to remove
unrelated files which look like backup files.
Ah, I see. If we never reach the part of the code where the pstore gets
written to disk, then there should be no backup. If one does exist,
then we didn’t create it on this run.
The code should still be fixed so orig gets set, wherever it is supposed
to be set. There’s a similar case on line 102 where orig is always
true.
I agree, but note that the backup file disappears if writing to the file
fails. You cannot depend on its existence.
Hmm, I assume the author (me) wanted back files to exist when
- the pstore file had existed before the transaction
- and pstore file had changed by the transaction
So I thought it’s natural to restore original file by renaming it from
the backup. If there’s no backup files, we can assume no modification
has done by the last transaction. Am I wrong somewhere?
You are correct. This isn’t immediately obvious, though, from the code.
Paul
···
On Sun, May 11, 2003 at 03:13:13AM +0900, Yukihiro Matsumoto wrote:
Karsten Thygesen wrote:
matz@ruby-lang.org (Yukihiro Matsumoto) writes:
Hmm…Where can I read more about PStore?
More than Pickaxe? Not in English, sorry. You can ask here if you
have questions.
So it is documented in the Pickaxe? Hmm…I will have to look again -
it’s not in the index…
Karsten
Sure it is. It’s listed on page 556 in the index, where you’ll be
directed to pp. 458-460.
Quick summary - The PStore class allows you to store Ruby objects to a
file.
Regards,
Dan
Paul,
The code should still be fixed so orig gets set,
wherever it is supposed to be set. There’s a
similar case on line 102 where orig is always
true.
If you look at line 94 where orig is set ("orig = true") you'll see that
it is inside a begin/rescue clause. If the pstore file does not exist, and
read_only is false (the default), then the “orig = true” line will never be
executed and orig will be nil. This allows orig to be used as a flag to
tell whether there was already a file there (true) or not (nil). The code
appears to be correct.
I hope this helps.
- Warren Brown