x_(hu4jnn) newer than x_(n0vm93) ?

[Rozek]

Hello!

I just visited the PureBasic site to see if there would be a new version available for download - and was quite surprised that the current version for MacOSX had a smaller build "number" than the one I got in january (namely (hu4jnn) instead of (n0vm93)).

The Windows version has a larger build number (as one would expect)

Does anybody know what this discrepancy means? Did Fantaisie Software had to go back to an older version for MacOSX? Or are build numbers pure phantasy ?

Thanks in advance for any response!

Kind regards,

A.Rozek

[Rings]

this name in the downloadfile had nothing to do with versionnumber

[Rozek]

Wow, that was fast!

Thanks for the immediate response!

Thus, these "numbers" are completely random? That makes it a bit more difficult to hold several versions of PureBasic in the same folder (when sorted by name - which is my default), but, well...I will survive!

Thanks anyway for the immediate response!

Kind regards,

A.Rozek

[SFSxOI]

sort them by date maybe ?

[Mistrel]

If the download is an arbitrary stream and not a direct link I don't see why random information needs to be added to the filename. Regardless, if the user is required to be logged in to access the download then the whole idea is completely redundant anyways.

[Little John]

Thus, these "numbers" are completely random? That makes it a bit more difficult to hold several versions of PureBasic in the same folder (when sorted by name - which is my default), but, well...I will survive!

After downloading, I always give the files meaningful names such as

PureBasic_4_30_Win_x86.exe
PureBasic_4_30_Lnx.tgz

Regards, Little John

[rsts]

If the download is an arbitrary stream and not a direct link I don't see why random information needs to be added to the filename. Regardless, if the user is required to be logged in to access the download then the whole idea is completely redundant anyways.

However. if it's not arbitrary, it may not be redundant.

cheers

[Mistrel]

If the file is passed to the user as a stream with an unknown location then it's not possible to link to it or to know where it's coming from. If the folder the file is located in is locked down using .htaccess then it will be impossible for the user to access it outside of the stream. If the stream is only accessible when the user is logged in.. then there's no point in using any further obsfucation.

My point is that if it originates as a stream then adding random letters to the filename is already redundant, unless the file being linked to has the same name, which wouldn't be an issue if .htaccess is used to block access.

[rsts]

But if the letters are not random, it may provide some level of traceability, should the file show up somewhere else.

[Mistrel]

But if the letters are not random, it may provide some level of traceability, should the file show up somewhere else.

You do have a point there.

[Trond]

The current solution was probably chosen because of its ease of implementation, not its technical merits.

Using a htaccess file for all the registered users would probably kill performance.

[Mistrel]

I don't think a simple

Code: Select all

<Files /files/PureBasic.exe>
order allow,deny
deny from all
</Files>

Would kill performance.

[idle]

Probably just a session Identifier being tacked on to the file name from a DB query after looking up the user. You can name your stream whatever you want.

Something like this in PHP

Code: Select all

$content_len=@filesize("SecretPathToTheFile/ItsName.exe"); 
Header("Content-type: application/exe"); 
Header("Content-type: octet-stream"); 
Header('Content-Disposition: attachment; filename="WhatEverName.exe"'); 
if($content_len!=FALSE) 
{ 
Header("Content-length: $content_len"); 
} 
readfile("SecretPathToTheFile/ItsName.exe"); 

//do logging to db ...

exit;

[Trond]

I don't think a simple

Code: Select all

<Files /files/PureBasic.exe>
order allow,deny
deny from all
</Files>

Would kill performance.

It wouldn't, but then no one could get the file...