mIRC Home    About    Download    Register    News    Help

Print Thread
problems with fopen #74494 08/03/04 11:16 PM
Joined: Dec 2002
Posts: 31
N
Netchelandorious Offline OP
Ameglian cow
OP Offline
Ameglian cow
N
Joined: Dec 2002
Posts: 31
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

Re: problems with fopen #74495 10/03/04 01:28 AM
Joined: Aug 2003
Posts: 1,831
I
Iori Offline
Hoopy frood
Offline
Hoopy frood
I
Joined: Aug 2003
Posts: 1,831
What exactly is the bug?

Re: problems with fopen #74496 10/03/04 02:20 AM
Joined: Jan 2003
Posts: 3,012
KingTomato Offline
Hoopy frood
Offline
Hoopy frood
Joined: Jan 2003
Posts: 3,012
I think they are referring to this post to which you already answered on Iori >:D


-KingTomato
Re: problems with fopen #74497 10/03/04 02:30 AM
Joined: Aug 2003
Posts: 1,831
I
Iori Offline
Hoopy frood
Offline
Hoopy frood
I
Joined: Aug 2003
Posts: 1,831
Well you linked to the same post as OP and I didn't reply to that (nor did anyone else). wink

Re: problems with fopen #74498 10/03/04 04:09 AM
Joined: Jan 2003
Posts: 3,012
KingTomato Offline
Hoopy frood
Offline
Hoopy frood
Joined: Jan 2003
Posts: 3,012
Rofl, sorry. Senior moment blush

try this one.


-KingTomato
Re: problems with fopen #74499 10/03/04 04:58 PM
Joined: Dec 2002
Posts: 31
N
Netchelandorious Offline OP
Ameglian cow
OP Offline
Ameglian cow
N
Joined: Dec 2002
Posts: 31
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.

Re: problems with fopen #74500 10/03/04 06:16 PM
Joined: Aug 2003
Posts: 1,831
I
Iori Offline
Hoopy frood
Offline
Hoopy frood
I
Joined: Aug 2003
Posts: 1,831
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. smile

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
}
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.


Re: problems with fopen #74501 11/03/04 02:03 AM
Joined: Dec 2002
Posts: 31
N
Netchelandorious Offline OP
Ameglian cow
OP Offline
Ameglian cow
N
Joined: Dec 2002
Posts: 31
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).

Re: problems with fopen #74502 11/03/04 07:06 PM
Joined: Aug 2003
Posts: 1,831
I
Iori Offline
Hoopy frood
Offline
Hoopy frood
I
Joined: Aug 2003
Posts: 1,831
ROFL I think most people understand that not writing/saving any changes to a file is not going to change its size. laugh

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],&amp;a) }
  echo -a $!feof: $feof -=- .pos: $fopen(name).pos
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..

Re: problems with fopen #74503 26/03/04 06:24 PM
Joined: Dec 2002
Posts: 4,543
Khaled Offline
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 4,543
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.