problems with fopen - 08/03/04 11:16 PM
Apparently I didn't get noticed last time? New version and nothing done about it. I thought a fix would be simple.
the original post
the original post
Re: problems with fopen - 10/03/04 01:28 AM
What exactly is the bug?
Re: problems with fopen - 10/03/04 02:20 AM
I think they are referring to this post to which you already answered on Iori >:D
Re: problems with fopen - 10/03/04 02:30 AM
Well you linked to the same post as OP and I didn't reply to that (nor did anyone else). 
Re: problems with fopen - 10/03/04 04:09 AM
Re: problems with fopen - 10/03/04 04:58 PM
The bug (?) is perhaps that $file().size doesn't reflect the actual file size when a file is opened with /fopen. After reflecting on the issue, I now understand how this kind of behavior might be expected and so not considered to be a bug. However, there is the necessity to be able to know the actual file size when you're writing to a file. So, included in my post is the feature suggestion is that $fopen could have an additional property for the file size (which may be faster than using $file().size anyways).
Also mentioned in the linked post is that $fopen().pos does not report the actual position in the file (or at least I wouldn't call it a position in the file). /fseek can be told to move the position to any given number, regardless of whether it is beyond the bounds of the file, and $fopen().pos will return that very same number. Is that not a bug?
No, KingTomato. I linked the post that I was referring to, I was not referring to the post that you linked.
Also mentioned in the linked post is that $fopen().pos does not report the actual position in the file (or at least I wouldn't call it a position in the file). /fseek can be told to move the position to any given number, regardless of whether it is beyond the bounds of the file, and $fopen().pos will return that very same number. Is that not a bug?
No, KingTomato. I linked the post that I was referring to, I was not referring to the post that you linked.
Re: problems with fopen - 10/03/04 06:16 PM
The bug (?) is perhaps that $file().size doesn't reflect the actual file size when a file is opened with /fopen. After reflecting on the issue, I now understand how this kind of behavior might be expected and so not considered to be a bug. However, there is the necessity to be able to know the actual file size when you're writing to a file. So, included in my post is the feature suggestion is that $fopen could have an additional property for the file size (which may be faster than using $file().size anyways).
Yeah I agree that a .size property could be useful. That belongs in Feature Suggestions.
Also mentioned in the linked post is that $fopen().pos does not report the actual position in the file
Yes it does.
/fseek can be told to move the position to any given number, regardless of whether it is beyond the bounds of the file, and $fopen().pos will return that very same number. Is that not a bug?
Actually no, because that IS where the pointer is at.
The pointer was at byte 12 after /fseek, then we wrote 1 byte, both $fopen().pos and $file().size show exactly that. As you can see, there is actually 12 char0's at the beginning of the file.
Yeah I agree that a .size property could be useful. That belongs in Feature Suggestions.
Also mentioned in the linked post is that $fopen().pos does not report the actual position in the file
Yes it does.
/fseek can be told to move the position to any given number, regardless of whether it is beyond the bounds of the file, and $fopen().pos will return that very same number. Is that not a bug?
Actually no, because that IS where the pointer is at.
Code:
alias nobug {
var %a = $ticks $+ .txt
.fopen -n abc %a
.fseek abc 12
.fwrite abc 1
var %b = $fopen(abc).pos
.fclose abc
bread %a 0 13 &abc
echo -ai %b -=- $file(%a).size <- They are the same, showing that /fseek actually did seek to that point before we wrote 1 byte.
echo -ai $bvar(&abc,1-) <- 12 x $!chr(0) plus 1 $!chr(49)
.remove %a
}
Re: problems with fopen - 11/03/04 02:03 AM
How about sticking to exactly what I said? Adding a possibly undesirable operation to the script (maybe I don't want to be writing to the file at position 12?) in an attempt to prove that $fopen().pos correctly reports the position in the file doesn't cut it. I had assumed that it functioned as you showed it did, but in between /fseek and /fwrite $fopen().pos does not report the position in the file.
alias nobug {
var %a = $ticks $+ .txt
.fopen -n abc %a
.fseek abc 12
var %b = $fopen(abc).pos
.fclose abc
echo -ai $file(%a).size <- the actual file size
echo -ai %b <- the reported position of the file, proving that $+($, fopen().pos) does not return the position in the file
.remove %a
}
Yes. After you WRITE to the file at position 12, THEN $fopen().pos returns the correct position. But if you /fseek past the end of the file, $fopen().pos does NOT return the correct position IN THE FILE. Since /fseek doesn't increase the file size, it can't possibly be returning the position in the file when you seek past the end.
But in case you didn't notice, my whole issue is with finding out the file size without having to close the file (and reopen if needing to resume file operations).
alias nobug {
var %a = $ticks $+ .txt
.fopen -n abc %a
.fseek abc 12
var %b = $fopen(abc).pos
.fclose abc
echo -ai $file(%a).size <- the actual file size
echo -ai %b <- the reported position of the file, proving that $+($, fopen().pos) does not return the position in the file
.remove %a
}
Yes. After you WRITE to the file at position 12, THEN $fopen().pos returns the correct position. But if you /fseek past the end of the file, $fopen().pos does NOT return the correct position IN THE FILE. Since /fseek doesn't increase the file size, it can't possibly be returning the position in the file when you seek past the end.
But in case you didn't notice, my whole issue is with finding out the file size without having to close the file (and reopen if needing to resume file operations).
Re: problems with fopen - 11/03/04 07:06 PM
ROFL I think most people understand that not writing/saving any changes to a file is not going to change its size. 
My post was not about the size of the file or whether or not you wanted to write anything at the fseeked postion, but to show that after "/fseek 81203948074523" the fact that $fopen().pos returns 81203948074523 is correct. If you make no changes to the file after the /fseek (at a position greater than the original eof) then obviously no change will be made to file regarding it.
But in case you didn't notice, my whole issue is with finding out the file size without having to close the file (and reopen if needing to resume file operations).
Well I did gather that from your original post, but has assumed that you would have worked that part out already.
The 1048576 can be adjusted up or down according to likes/dislikes or perhaps speed issues on different systems or with dirrerent sized file. I simple used 1 MB as an arbituary number..
My post was not about the size of the file or whether or not you wanted to write anything at the fseeked postion, but to show that after "/fseek 81203948074523" the fact that $fopen().pos returns 81203948074523 is correct. If you make no changes to the file after the /fseek (at a position greater than the original eof) then obviously no change will be made to file regarding it.
But in case you didn't notice, my whole issue is with finding out the file size without having to close the file (and reopen if needing to resume file operations).
Well I did gather that from your original post, but has assumed that you would have worked that part out already.
Code:
while !$feof { .echo -q $fread(name,[color:plum]1048576[/color],&a) }
echo -a $!feof: $feof -=- .pos: $fopen(name).pos
Re: problems with fopen - 26/03/04 06:24 PM
This behaviour is purposeful and is the way files work under Windows. The Windows SDK description of SetFilePointer describes the situation you mention and indicates that this is how it normally works.