Skip to content

current file pointer jumps to the end when file grows after it has been opened #1474

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
brandy125 opened this issue Jan 14, 2023 · 15 comments
Closed

current file pointer jumps to the end when file grows after it has been opened #1474

brandy125 opened this issue Jan 14, 2023 · 15 comments

Comments

@brandy125
Copy link

The current file pointer must stay at position 100000 even if the file grows:

GDL> openw,1,'eraseme'
GDL> line1=bytarr(1000)
GDL> for i=0,99 do writeu,1,line1
GDL> flush,1
GDL> 
GDL> openr,2,'eraseme'
GDL> line2=bytarr(1000)
GDL> for i=0,99 do readu,2,line2
GDL> print,fstat(1)
{ 1 eraseme   1   0   0   0   0   0   1   1  1673731066 1673731024 1673731024 0 100000 100000  0}
GDL> print,fstat(2)
{ 2 eraseme   1   0   0   0   0   0   1   0  1673731066 1673731024 1673731024 0 100000 100000  0}

up to here it is correct. But if we increase the file size then the current pointer must stay at position 100000 as it is in IDL. It must not jump to 200000 which is the size of the file.

GDL> for i=0,99 do writeu,1,line
GDL> flush,1
GDL> print,fstat(2)
{ 2 eraseme   1   0   0   0   0   0   1   0 1673731066 1673731087 1673731087 0 200000 200000 0}
@brandy125
Copy link
Author

Can anybody help here? I would need a solution for this since I am working with realtime data right now and this is a "no go".
Thanks!

@alaingdl
Copy link
Contributor

alaingdl commented Feb 7, 2023

1/ reproduced
2/ seems to be related to method Tell(p in io.cpp which does not distinguish between reading and writing case

@alaingdl
Copy link
Contributor

alaingdl commented Feb 7, 2023

I changed your code in such a way :

pro test_issues1474, maxi=maxi

if ~keyword_set(maxi) then maxi=99

close,1, 2

openw,1,'eraseme'
line1=bytarr(1000)
for i=0,99 do writeu,1,line1
flush,1

openr,2,'eraseme'
line2=bytarr(1000)
for i=0,maxi do readu,2,line2
f1=fstat(1) & print, 'f1 :', f1.unit, f1.cur_ptr, f1.size
f2=fstat(2) & print, 'f2 :', f2.unit, f2.cur_ptr, f2.size
;print,fstat(1)
;print,fstat(2)

for i=0,99 do writeu,1,line1
flush,1
f1=fstat(1) & print, 'f1 :', f1.unit, f1.cur_ptr, f1.size
f2=fstat(2) & print, 'f2 :', f2.unit, f2.cur_ptr, f2.size
;print,fstat(2)

stop
end

What is really strange is that if maxi is less than 99 the code is OK :(

May be a problem in the line
if (actUnit.Eof()) pos=buffer.st_size; else pos=actUnit.Tell() because we play with the limit ?

GillesDuvert added a commit to GillesDuvert/gdl that referenced this issue Feb 7, 2023
@GillesDuvert
tentaively solve gnudatalanguage#1474
7f227ff
@GillesDuvert
Copy link
Contributor

please try patch #1502

@alaingdl
Copy link
Contributor

alaingdl commented Feb 7, 2023

Ok, thanks @GillesDuvert

On my side I arrived to that fact that the
bool AnyStream::Eof() { is not OK, and just removing

    //    fStream->clear(); // clear old EOF	
    //    fStream->peek(); // trigger EOF if at EOF

is enough to solve the problem (but with which side effect ?)

I will check tomorrow you patch

@GillesDuvert GillesDuvert mentioned this issue Feb 9, 2023
Merged
GillesDuvert added a commit that referenced this issue Feb 10, 2023
@GillesDuvert
Merge pull request #1502 from GillesDuvert/solve_1474_tentative
edeb99e 
tentatively solve #1474
MERGING AS MAC AND WINDOWS FAILURES ARE NOT RELEVANT TO THIS IMPORTANT PR
@GillesDuvert
Copy link
Contributor

solved.

@brandy125
Copy link
Author

brandy125 commented Feb 10, 2023 via email

@alaingdl
Copy link
Contributor

yes, you have to do that :
git submodule update --init
it will add the files needed in the src/whereami sub-dir

@brandy125
Copy link
Author

brandy125 commented Feb 10, 2023 via email

@alaingdl
Copy link
Contributor

where you have the .gitmodules & .gitignore files.

or, after, in the path where you did git pull

@brandy125
Copy link
Author

brandy125 commented Feb 10, 2023 via email

@alaingdl
Copy link
Contributor

Very strange ! Could you create a new dir, then make :

git clone https://github.com/gnudatalanguage/gdl
cd gdl
git submodule update --init

That is working for me

@brandy125
Copy link
Author

brandy125 commented Feb 10, 2023 via email

@GillesDuvert
Copy link
Contributor

Ouch, GitHub does not know about submodules?
I created https://github.com/gnudatalanguage/gdl/wiki/Cloning-gnudatalanguage-gdl but this is not satisfactory.
GitHub should support 'submodules' fully in this
image
button

Strange that nobody complained to GH since it is so frequent.

@slayoo
Copy link
Member

slayoo commented Feb 11, 2023

The lack of submodule content in source archives is the topic of #1496.
We will workaround it by creating our own archives within the weekly and main releases.
This was reported to GitHub long long time ago, but seems to be tricky to solve (due to security reasons?): dear-github/dear-github#214

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@slayoo @GillesDuvert @alaingdl @brandy125