I'm using this command below to download a file from own server:
::http::geturl $url -binary 1 -progress $callbackproc
The callback procedure is used to show a progress bar in the UI.
On some computers to which I don't have access, the download works
but the progress bar is not updated until the complete file is
downloaded. It looks like the download is blocking the whole time.
Alexandru <[email protected]> wrote:
I'm using this command below to download a file from own server:Can you determine whether the callback is actually called?
::http::geturl $url -binary 1 -progress $callbackproc
The callback procedure is used to show a progress bar in the UI.
On some computers to which I don't have access, the download works
but the progress bar is not updated until the complete file is
downloaded. It looks like the download is blocking the whole time.
Merely from reading it, it could be circumstances that would
either prevent the callback from being called at all, or just
prevent the gui from being updated to reflect the progressbar
updates.
Maybe, the "readable" events from socket are so fast coming in,
that the "idletask" for redrawing the progressbar starves...
Does your callback code call update idletasks? -- not sure if
it even should... but it might be something to try...
Andreas Leitgeb schrieb am Dienstag, 25. Juli 2023 um 08:59:00 UTC+2:
Alexandru <[email protected]> wrote:
I'm using this command below to download a file from own server:Can you determine whether the callback is actually called?
::http::geturl $url -binary 1 -progress $callbackproc
The callback procedure is used to show a progress bar in the UI.
On some computers to which I don't have access, the download works
but the progress bar is not updated until the complete file is downloaded. It looks like the download is blocking the whole time.
Merely from reading it, it could be circumstances that would
either prevent the callback from being called at all, or just
prevent the gui from being updated to reflect the progressbar
updates.
Maybe, the "readable" events from socket are so fast coming in,
that the "idletask" for redrawing the progressbar starves...
Does your callback code call update idletasks? -- not sure ifThanks Andreas. The callback should be called, since I can see how the progress bar is initialized and how it jups to 100% at the end of the download.
it even should... but it might be something to try...
The callback also calls "update" without the "idletasks" argument, because I had the experience, that "update idletasks" does not work.
The code runs on different machines of different customers. In 90% of the cases there is no issue. For me it looks like the 10% have some network configurations that are incompatible with my code.
Again: The code on the client PC starts the download from a server computer that is also fixed (always the same).
I suppose the issue is either something missing on the server or on the client.
Until now those are only suppositions.
I hope somebody made similar experiences and knows the solution.
Thanks Andreas. The callback should be called, since I can see how
the progress bar is initialized and how it jups to 100% at the end of
the download. The callback also calls "update" without the
"idletasks" argument, because I had the experience, that "update
idletasks" does not work. The code runs on different machines of
different customers. In 90% of the cases there is no issue. For me
it looks like the 10% have some network configurations that are
incompatible with my code. Again: The code on the client PC starts
the download from a server computer that is also fixed (always the
same). I suppose the issue is either something missing on the server
or on the client. Until now those are only suppositions. I hope
somebody made similar experiences and knows the solution.
Alexandru <[email protected]> wrote:
Rich schrieb am Dienstag, 25. Juli 2023 um 15:00:56 UTC+2:
Alexandru <[email protected]> wrote:
Thanks Andreas. The callback should be called, since I can see howYou appear to have omitted the possibility that those 10% have a
the progress bar is initialized and how it jups to 100% at the end of
the download. The callback also calls "update" without the
"idletasks" argument, because I had the experience, that "update
idletasks" does not work. The code runs on different machines of
different customers. In 90% of the cases there is no issue. For me
it looks like the 10% have some network configurations that are
incompatible with my code. Again: The code on the client PC starts
the download from a server computer that is also fixed (always the
same). I suppose the issue is either something missing on the server
or on the client. Until now those are only suppositions. I hope
somebody made similar experiences and knows the solution.
network link of sufficient speed that the download occurs fast enough
that "initialize --- 100% done" is actually accurate.
How large is the file being downloaded, and what is the network
performace for those that see "direct to 100%" during the download?
And, while you imply so, for those that see direct to 100%, do they
have the full file when the download ends?
The file 27MB large and the networks speed is rather slow.But, is that for you, or for the 10%? I.e., are the 10% behind some
I know that, because it takes a minute or so to finish the download.
form of caching proxy that has your 27MB file cached, and they are on
10G or better ethernet to that caching proxy, such that for them a 27MB download does indeed finish nearly instantly?
Yes the file is fully downloaded when the progress jumps to 100%Ok, that rules out 100% being indicated without the file actually being
because the file is an executable and it runs correctly after that.
fully downloaded.
Andreas Leitgeb schrieb am Dienstag, 25. Juli 2023 um 08:59:00 UTC+2:
Does your callback code call update idletasks? -- not sure ifThanks Andreas. The callback should be called, since I can see how the progress bar is initialized and how it jups to 100% at the end of the download.
it even should... but it might be something to try...
The callback also calls "update" without the "idletasks" argument,
because I had the experience, that "update idletasks" does not work.
The code runs on different machines of different customers. In 90% of the cases there is no issue. For me it looks like the 10% have some network configurations that are incompatible with my code.
Alexandru <[email protected]> wrote:
Thanks Andreas. The callback should be called, since I can see howYou appear to have omitted the possibility that those 10% have a
the progress bar is initialized and how it jups to 100% at the end of
the download. The callback also calls "update" without the
"idletasks" argument, because I had the experience, that "update
idletasks" does not work. The code runs on different machines of
different customers. In 90% of the cases there is no issue. For me
it looks like the 10% have some network configurations that are incompatible with my code. Again: The code on the client PC starts
the download from a server computer that is also fixed (always the
same). I suppose the issue is either something missing on the server
or on the client. Until now those are only suppositions. I hope
somebody made similar experiences and knows the solution.
network link of sufficient speed that the download occurs fast enough
that "initialize --- 100% done" is actually accurate.
How large is the file being downloaded, and what is the network
performace for those that see "direct to 100%" during the download?
And, while you imply so, for those that see direct to 100%, do they
have the full file when the download ends?
Rich schrieb am Dienstag, 25. Juli 2023 um 15:00:56 UTC+2:
Alexandru <[email protected]> wrote:
Thanks Andreas. The callback should be called, since I can see howYou appear to have omitted the possibility that those 10% have a
the progress bar is initialized and how it jups to 100% at the end of
the download. The callback also calls "update" without the
"idletasks" argument, because I had the experience, that "update
idletasks" does not work. The code runs on different machines of
different customers. In 90% of the cases there is no issue. For me
it looks like the 10% have some network configurations that are
incompatible with my code. Again: The code on the client PC starts
the download from a server computer that is also fixed (always the
same). I suppose the issue is either something missing on the server
or on the client. Until now those are only suppositions. I hope
somebody made similar experiences and knows the solution.
network link of sufficient speed that the download occurs fast enough
that "initialize --- 100% done" is actually accurate.
How large is the file being downloaded, and what is the network
performace for those that see "direct to 100%" during the download?
And, while you imply so, for those that see direct to 100%, do they
have the full file when the download ends?
The file 27MB large and the networks speed is rather slow.
I know that, because it takes a minute or so to finish the download.
Yes the file is fully downloaded when the progress jumps to 100%
because the file is an executable and it runs correctly after that.
Rich schrieb am Dienstag, 25. Juli 2023 um 15:00:56 UTC+2:
Alexandru <[email protected]> wrote:
Thanks Andreas. The callback should be called, since I can see howYou appear to have omitted the possibility that those 10% have a
the progress bar is initialized and how it jups to 100% at the end of
the download. The callback also calls "update" without the
"idletasks" argument, because I had the experience, that "update
idletasks" does not work. The code runs on different machines of
different customers. In 90% of the cases there is no issue. For me
it looks like the 10% have some network configurations that are
incompatible with my code. Again: The code on the client PC starts
the download from a server computer that is also fixed (always the
same). I suppose the issue is either something missing on the server
or on the client. Until now those are only suppositions. I hope
somebody made similar experiences and knows the solution.
network link of sufficient speed that the download occurs fast enough
that "initialize --- 100% done" is actually accurate.
How large is the file being downloaded, and what is the network
performace for those that see "direct to 100%" during the download?
And, while you imply so, for those that see direct to 100%, do they
have the full file when the download ends?
The file 27MB large and the networks speed is rather slow.
I know that, because it takes a minute or so to finish the download.
Yes the file is fully downloaded when the progress jumps to 100% because the file is an executable and it runs correctly after that.
et99 schrieb am Sonntag, 30. Juli 2023 um 20:21:27 UTC+2:that most of the transfers have some default values where the total file size is transfered through the http headers. And that some others block this option. Maybe the -blocksize option can fix this, I'll try to see what exactly the source code does with
On 7/25/2023 6:23 AM, Alexandru wrote:
Rich schrieb am Dienstag, 25. Juli 2023 um 15:00:56 UTC+2:
Alexandru <[email protected]> wrote:
Thanks Andreas. The callback should be called, since I can see howYou appear to have omitted the possibility that those 10% have a
the progress bar is initialized and how it jups to 100% at the end of >>> the download. The callback also calls "update" without the
"idletasks" argument, because I had the experience, that "update
idletasks" does not work. The code runs on different machines of
different customers. In 90% of the cases there is no issue. For me
it looks like the 10% have some network configurations that are
incompatible with my code. Again: The code on the client PC starts
the download from a server computer that is also fixed (always the
same). I suppose the issue is either something missing on the server >>> or on the client. Until now those are only suppositions. I hope
somebody made similar experiences and knows the solution.
network link of sufficient speed that the download occurs fast enough >> that "initialize --- 100% done" is actually accurate.
How large is the file being downloaded, and what is the network
performace for those that see "direct to 100%" during the download?
And, while you imply so, for those that see direct to 100%, do they
have the full file when the download ends?
The file 27MB large and the networks speed is rather slow.Hi Alexandru, did you ever solve this?
I know that, because it takes a minute or so to finish the download.
Yes the file is fully downloaded when the progress jumps to 100% because the file is an executable and it runs correctly after that.
-progress callback returns the token and 2 values, the
total expected size, and the current size.
The expected size is returned via the content-Length
meta-data but: "The expected total size may be
unknown, in which case zero is passed to the callback. "
I presume you use the current size but could it be
that the expected size is being returned as 0? Do you
check for that value, and if so, what do you do with a
0? Might you be just returning from the callback and
not updating the gui?
Perhaps the http code knows the expected size only
when the transfer is finished, and so just fills in
both values using the final current size? I'm assuming
you do get a callback with both values the same,
indicating 100%
Are you using ttk::progressbar for the progress? It
has an indeterminate mode which you could use along
with an entry or label widget with the current size of
the transfer, if indeed you are getting 0 for the
expected size.
Also, there's an option -blocksize size which affectsIt's not solved yet. I added a new option to the header (-headers [list Accept-Encoding "gzip, deflate"] ) beased on some help from general http threads but since I cannot reproduce the issue, I need to wait for feedback from users.
when the callback is invoked, I wonder what its
default value might be.
Your tipp with -blocksize is also interesting, that is also worth a try.
Ans yes, I also suppose that for some client-server combinations, the total size is not known, so the callback is called one 2 times, with 0% and 100%. The question is rather, when and why it can happen that the file size is not tranfered? I suppose
On 7/25/2023 6:23 AM, Alexandru wrote:It's not solved yet. I added a new option to the header (-headers [list Accept-Encoding "gzip, deflate"] ) beased on some help from general http threads but since I cannot reproduce the issue, I need to wait for feedback from users.
Rich schrieb am Dienstag, 25. Juli 2023 um 15:00:56 UTC+2:
Alexandru <[email protected]> wrote:
Thanks Andreas. The callback should be called, since I can see howYou appear to have omitted the possibility that those 10% have a
the progress bar is initialized and how it jups to 100% at the end of >>> the download. The callback also calls "update" without the
"idletasks" argument, because I had the experience, that "update
idletasks" does not work. The code runs on different machines of
different customers. In 90% of the cases there is no issue. For me
it looks like the 10% have some network configurations that are
incompatible with my code. Again: The code on the client PC starts
the download from a server computer that is also fixed (always the
same). I suppose the issue is either something missing on the server
or on the client. Until now those are only suppositions. I hope
somebody made similar experiences and knows the solution.
network link of sufficient speed that the download occurs fast enough
that "initialize --- 100% done" is actually accurate.
How large is the file being downloaded, and what is the network
performace for those that see "direct to 100%" during the download?
And, while you imply so, for those that see direct to 100%, do they
have the full file when the download ends?
The file 27MB large and the networks speed is rather slow.Hi Alexandru, did you ever solve this?
I know that, because it takes a minute or so to finish the download.
Yes the file is fully downloaded when the progress jumps to 100% because the file is an executable and it runs correctly after that.
-progress callback returns the token and 2 values, the
total expected size, and the current size.
The expected size is returned via the content-Length
meta-data but: "The expected total size may be
unknown, in which case zero is passed to the callback. "
I presume you use the current size but could it be
that the expected size is being returned as 0? Do you
check for that value, and if so, what do you do with a
0? Might you be just returning from the callback and
not updating the gui?
Perhaps the http code knows the expected size only
when the transfer is finished, and so just fills in
both values using the final current size? I'm assuming
you do get a callback with both values the same,
indicating 100%
Are you using ttk::progressbar for the progress? It
has an indeterminate mode which you could use along
with an entry or label widget with the current size of
the transfer, if indeed you are getting 0 for the
expected size.
Also, there's an option -blocksize size which affects
when the callback is invoked, I wonder what its
default value might be.
Alexandru schrieb am Sonntag, 30. Juli 2023 um 21:40:17 UTC+2:that most of the transfers have some default values where the total file size is transfered through the http headers. And that some others block this option. Maybe the -blocksize option can fix this, I'll try to see what exactly the source code does with
et99 schrieb am Sonntag, 30. Juli 2023 um 20:21:27 UTC+2:
On 7/25/2023 6:23 AM, Alexandru wrote:It's not solved yet. I added a new option to the header (-headers [list Accept-Encoding "gzip, deflate"] ) beased on some help from general http threads but since I cannot reproduce the issue, I need to wait for feedback from users.
Rich schrieb am Dienstag, 25. Juli 2023 um 15:00:56 UTC+2:Hi Alexandru, did you ever solve this?
Alexandru <[email protected]> wrote:
Thanks Andreas. The callback should be called, since I can see how >>>>>> the progress bar is initialized and how it jups to 100% at the end of >>>>>> the download. The callback also calls "update" without theYou appear to have omitted the possibility that those 10% have a
"idletasks" argument, because I had the experience, that "update
idletasks" does not work. The code runs on different machines of
different customers. In 90% of the cases there is no issue. For me >>>>>> it looks like the 10% have some network configurations that are
incompatible with my code. Again: The code on the client PC starts >>>>>> the download from a server computer that is also fixed (always the >>>>>> same). I suppose the issue is either something missing on the server >>>>>> or on the client. Until now those are only suppositions. I hope
somebody made similar experiences and knows the solution.
network link of sufficient speed that the download occurs fast enough >>>>> that "initialize --- 100% done" is actually accurate.
How large is the file being downloaded, and what is the network
performace for those that see "direct to 100%" during the download?
And, while you imply so, for those that see direct to 100%, do they
have the full file when the download ends?
The file 27MB large and the networks speed is rather slow.
I know that, because it takes a minute or so to finish the download.
Yes the file is fully downloaded when the progress jumps to 100% because the file is an executable and it runs correctly after that.
-progress callback returns the token and 2 values, the
total expected size, and the current size.
The expected size is returned via the content-Length
meta-data but: "The expected total size may be
unknown, in which case zero is passed to the callback. "
I presume you use the current size but could it be
that the expected size is being returned as 0? Do you
check for that value, and if so, what do you do with a
0? Might you be just returning from the callback and
not updating the gui?
Perhaps the http code knows the expected size only
when the transfer is finished, and so just fills in
both values using the final current size? I'm assuming
you do get a callback with both values the same,
indicating 100%
Are you using ttk::progressbar for the progress? It
has an indeterminate mode which you could use along
with an entry or label widget with the current size of
the transfer, if indeed you are getting 0 for the
expected size.
Also, there's an option -blocksize size which affects
when the callback is invoked, I wonder what its
default value might be.
Your tipp with -blocksize is also interesting, that is also worth a try.
Ans yes, I also suppose that for some client-server combinations, the total size is not known, so the callback is called one 2 times, with 0% and 100%. The question is rather, when and why it can happen that the file size is not tranfered? I suppose
-blocksize defaults to 8192 so it's small enough to show a smooth download progress for a 27MB large files.
So if cannot be the solution to user specify this value.
On 7/30/2023 12:54 PM, Alexandru wrote:that most of the transfers have some default values where the total file size is transfered through the http headers. And that some others block this option. Maybe the -blocksize option can fix this, I'll try to see what exactly the source code does with
Alexandru schrieb am Sonntag, 30. Juli 2023 um 21:40:17 UTC+2:
et99 schrieb am Sonntag, 30. Juli 2023 um 20:21:27 UTC+2:
On 7/25/2023 6:23 AM, Alexandru wrote:It's not solved yet. I added a new option to the header (-headers [list Accept-Encoding "gzip, deflate"] ) beased on some help from general http threads but since I cannot reproduce the issue, I need to wait for feedback from users.
Rich schrieb am Dienstag, 25. Juli 2023 um 15:00:56 UTC+2:Hi Alexandru, did you ever solve this?
Alexandru <[email protected]> wrote:
Thanks Andreas. The callback should be called, since I can see how >>>>>> the progress bar is initialized and how it jups to 100% at the end of >>>>>> the download. The callback also calls "update" without theYou appear to have omitted the possibility that those 10% have a
"idletasks" argument, because I had the experience, that "update >>>>>> idletasks" does not work. The code runs on different machines of >>>>>> different customers. In 90% of the cases there is no issue. For me >>>>>> it looks like the 10% have some network configurations that are >>>>>> incompatible with my code. Again: The code on the client PC starts >>>>>> the download from a server computer that is also fixed (always the >>>>>> same). I suppose the issue is either something missing on the server >>>>>> or on the client. Until now those are only suppositions. I hope >>>>>> somebody made similar experiences and knows the solution.
network link of sufficient speed that the download occurs fast enough >>>>> that "initialize --- 100% done" is actually accurate.
How large is the file being downloaded, and what is the network
performace for those that see "direct to 100%" during the download? >>>>>
And, while you imply so, for those that see direct to 100%, do they >>>>> have the full file when the download ends?
The file 27MB large and the networks speed is rather slow.
I know that, because it takes a minute or so to finish the download. >>>> Yes the file is fully downloaded when the progress jumps to 100% because the file is an executable and it runs correctly after that.
-progress callback returns the token and 2 values, the
total expected size, and the current size.
The expected size is returned via the content-Length
meta-data but: "The expected total size may be
unknown, in which case zero is passed to the callback. "
I presume you use the current size but could it be
that the expected size is being returned as 0? Do you
check for that value, and if so, what do you do with a
0? Might you be just returning from the callback and
not updating the gui?
Perhaps the http code knows the expected size only
when the transfer is finished, and so just fills in
both values using the final current size? I'm assuming
you do get a callback with both values the same,
indicating 100%
Are you using ttk::progressbar for the progress? It
has an indeterminate mode which you could use along
with an entry or label widget with the current size of
the transfer, if indeed you are getting 0 for the
expected size.
Also, there's an option -blocksize size which affects
when the callback is invoked, I wonder what its
default value might be.
Your tipp with -blocksize is also interesting, that is also worth a try. >> Ans yes, I also suppose that for some client-server combinations, the total size is not known, so the callback is called one 2 times, with 0% and 100%. The question is rather, when and why it can happen that the file size is not tranfered? I suppose
No, not yet. But this is highly prpbably, I'll check though. Need a cooperating customer first.-blocksize defaults to 8192 so it's small enough to show a smooth download progress for a 27MB large files.So, have you been able to determine if you're getting
So if cannot be the solution to user specify this value.
0 for expected file size on the systems that don't
update the progress bar?
What about platform, windows, unix, both? If both,I'm living in a Windows buble, no unix there.
does the problem occur on only one?
Your tipp with -blocksize is also interesting, that is also worth a try.
Ans yes, I also suppose that for some client-server combinations, the
total size is not known, so the callback is called one 2 times, with
0% and 100%. The question is rather, when and why it can happen that
the file size is not tranfered? I suppose that most of the transfers
have some default values where the total file size is transfered
through the http headers.
And that some others block this option.
Alexandru <[email protected]> wrote:
Your tipp with -blocksize is also interesting, that is also worth a try.That setting is used with [read] to determine how many bytes are read
from the socket at a time.
Ans yes, I also suppose that for some client-server combinations, theHTTP includes a header that provides for transferring the full size in
total size is not known, so the callback is called one 2 times, with
0% and 100%. The question is rather, when and why it can happen that
the file size is not tranfered? I suppose that most of the transfers
have some default values where the total file size is transfered
through the http headers.
bytes of the file -- but its use is not mandatory.
And that some others block this option.The headers are set by the serving webserver, so it is what determines whether the header showing the full file size is transferred.
You should add some debug logging to your code that logs each callback
from http::geturl and what the parameters are that get passed, and as
well log the http headers from the transfer to see what headers are
being transferred. Without knowing those two items, trying to fix this
will be like trying to shoot a bullseye while blindfolded.
et99 schrieb am Sonntag, 30. Juli 2023 um 22:11:01 UTC+2:that most of the transfers have some default values where the total file size is transfered through the http headers. And that some others block this option. Maybe the -blocksize option can fix this, I'll try to see what exactly the source code does with
On 7/30/2023 12:54 PM, Alexandru wrote:
Alexandru schrieb am Sonntag, 30. Juli 2023 um 21:40:17 UTC+2:
et99 schrieb am Sonntag, 30. Juli 2023 um 20:21:27 UTC+2:
On 7/25/2023 6:23 AM, Alexandru wrote:It's not solved yet. I added a new option to the header (-headers [list Accept-Encoding "gzip, deflate"] ) beased on some help from general http threads but since I cannot reproduce the issue, I need to wait for feedback from users.
Rich schrieb am Dienstag, 25. Juli 2023 um 15:00:56 UTC+2:Hi Alexandru, did you ever solve this?
Alexandru <[email protected]> wrote:
Thanks Andreas. The callback should be called, since I can see how >>>>>>>> the progress bar is initialized and how it jups to 100% at the end of >>>>>>>> the download. The callback also calls "update" without theYou appear to have omitted the possibility that those 10% have a >>>>>>> network link of sufficient speed that the download occurs fast enough >>>>>>> that "initialize --- 100% done" is actually accurate.
"idletasks" argument, because I had the experience, that "update >>>>>>>> idletasks" does not work. The code runs on different machines of >>>>>>>> different customers. In 90% of the cases there is no issue. For me >>>>>>>> it looks like the 10% have some network configurations that are >>>>>>>> incompatible with my code. Again: The code on the client PC starts >>>>>>>> the download from a server computer that is also fixed (always the >>>>>>>> same). I suppose the issue is either something missing on the server >>>>>>>> or on the client. Until now those are only suppositions. I hope >>>>>>>> somebody made similar experiences and knows the solution.
How large is the file being downloaded, and what is the network
performace for those that see "direct to 100%" during the download? >>>>>>>
And, while you imply so, for those that see direct to 100%, do they >>>>>>> have the full file when the download ends?
The file 27MB large and the networks speed is rather slow.
I know that, because it takes a minute or so to finish the download. >>>>>> Yes the file is fully downloaded when the progress jumps to 100% because the file is an executable and it runs correctly after that.
-progress callback returns the token and 2 values, the
total expected size, and the current size.
The expected size is returned via the content-Length
meta-data but: "The expected total size may be
unknown, in which case zero is passed to the callback. "
I presume you use the current size but could it be
that the expected size is being returned as 0? Do you
check for that value, and if so, what do you do with a
0? Might you be just returning from the callback and
not updating the gui?
Perhaps the http code knows the expected size only
when the transfer is finished, and so just fills in
both values using the final current size? I'm assuming
you do get a callback with both values the same,
indicating 100%
Are you using ttk::progressbar for the progress? It
has an indeterminate mode which you could use along
with an entry or label widget with the current size of
the transfer, if indeed you are getting 0 for the
expected size.
Also, there's an option -blocksize size which affects
when the callback is invoked, I wonder what its
default value might be.
Your tipp with -blocksize is also interesting, that is also worth a try. >>>> Ans yes, I also suppose that for some client-server combinations, the total size is not known, so the callback is called one 2 times, with 0% and 100%. The question is rather, when and why it can happen that the file size is not tranfered? I suppose
No, not yet. But this is highly prpbably, I'll check though. Need a cooperating customer first.So, have you been able to determine if you're getting
-blocksize defaults to 8192 so it's small enough to show a smooth download progress for a 27MB large files.
So if cannot be the solution to user specify this value.
0 for expected file size on the systems that don't
update the progress bar?
I'm living in a Windows buble, no unix there.
What about platform, windows, unix, both? If both,
does the problem occur on only one?
Exactly and the web server is a constant in all this. It's my server and the file is downloaded from my server.
So it must be something with the client, right?
On 7/30/2023 6:10 PM, Alexandru wrote:
Exactly and the web server is a constant in all this. It's my server and the file is downloaded from my server.
So it must be something with the client, right?
If the server is yours, try adding "Content-Length" header to the file downloads and see how that goes.
Windows, hmmm, and you're downloading an executable file. I've
always wondered how it knows that and creates a file with the blocked
status, which I have to unblock in properties. I wonder if that
could come into play here.
et99 <[email protected]> wrote:
Windows, hmmm, and you're downloading an executable file. I've
always wondered how it knows that and creates a file with the blocked
status, which I have to unblock in properties. I wonder if that
could come into play here.
That would seem to only come into play after the download is over,
rather than during.
And the how the file is marked, windows inserts a second stream into
the file with a particular bit of data inside that essentially says
"came from the internet". Then, later, if and when you go to execute
it, if windows finds the second stream present, it pops up the "we
don't know enough about this file, are you sure" dialog.
Clearing the second stream out is equal to using the properties to say
"I vouch for the file".
On 7/30/2023 6:08 PM, Rich wrote:
et99 <[email protected]> wrote:
Windows, hmmm, and you're downloading an executable file. I've
always wondered how it knows that and creates a file with the blocked
status, which I have to unblock in properties. I wonder if that
could come into play here.
That would seem to only come into play after the download is over,
rather than during.
And the how the file is marked, windows inserts a second stream into
the file with a particular bit of data inside that essentially says
"came from the internet". Then, later, if and when you go to execute
it, if windows finds the second stream present, it pops up the "we
don't know enough about this file, are you sure" dialog.
Clearing the second stream out is equal to using the properties to say
"I vouch for the file".
Interesting. A second stream, so I guess the application has
to participate in this. Windows wouldn't know on its own would
it?
That's what I wondered about, did windows see .exe in the
file name and do that w/o the app having to be involved.
I guess i only see this when I download with a browser, so
firefox could be the one adding this. Opening a file in tcl
then shouldn't do it, even with the .exe extension.
et99 <[email protected]> wrote:
On 7/30/2023 6:08 PM, Rich wrote:
et99 <[email protected]> wrote:
Windows, hmmm, and you're downloading an executable file. I've
always wondered how it knows that and creates a file with the blocked
status, which I have to unblock in properties. I wonder if that
could come into play here.
That would seem to only come into play after the download is over,
rather than during.
And the how the file is marked, windows inserts a second stream into
the file with a particular bit of data inside that essentially says
"came from the internet". Then, later, if and when you go to execute
it, if windows finds the second stream present, it pops up the "we
don't know enough about this file, are you sure" dialog.
Clearing the second stream out is equal to using the properties to say
"I vouch for the file".
Interesting. A second stream, so I guess the application has
to participate in this. Windows wouldn't know on its own would
it?
Since almost zero windows applications do anything with anything other
than the primary file stream, most apps are completely unaware.
Windows (as in the OS) itself is what is adding on the second stream,
and noticing its presence to pop up the "do you really want to run
this" dialog.
That's what I wondered about, did windows see .exe in the
file name and do that w/o the app having to be involved.
Windows adds the second streams itself. I don't know if they attach
them to all downloaded files, or just exe's. My guess is they attach
them to all downloads -- but the ones attached to files not named .exe
never trigger a "do you want to run this" dialog because they never get launched as an exe.
I guess i only see this when I download with a browser, so
firefox could be the one adding this. Opening a file in tcl
then shouldn't do it, even with the .exe extension.
Since it seems to happen for any kind of download I suspect windows
does it. But as the only time I concern myself with it is on $work
computer, I've never delved deeply into the who does what where and
when part of the labeling, only the "how to clear out the labeling"
part.
* Rich <[email protected]d>
| et99 <[email protected]> wrote:
| Windows (as in the OS) itself is what is adding on the second stream,
| and noticing its presence to pop up the "do you really want to run
| this" dialog.
| > That's what I wondered about, did windows see .exe in the
| > file name and do that w/o the app having to be involved.
| Windows adds the second streams itself. I don't know if they attach
| them to all downloaded files, or just exe's. My guess is they attach
| them to all downloads -- but the ones attached to files not named .exe
| never trigger a "do you want to run this" dialog because they never get
| launched as an exe.
These might have some more info on this:
https://www.itprotoday.com/mobile-management-and-security/how-does-windows-know-if-file-downloaded-internet
https://support.microsoft.com/en-gb/topic/information-about-the-attachment-manager-in-microsoft-windows-c48a4dcd-8de5-2af5-ee9b-cd795ae42738
A quick glance in my Windows Downloads folder shows the Zone.Identifier files/streams for several file types, not only .exe.
HTH
R'
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 716 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 52:14:08 |
| Calls: | 12,115 |
| Calls today: | 6 |
| Files: | 15,010 |
| Messages: | 6,518,584 |
| Posted today: | 1 |