Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - LeoNeeson

Pages: [1] 2 3 ... 32
Bug reports / Re: HFS not able to start.
« on: October 14, 2018, 07:22:14 AM »
I went and followed your steps. I downloaded the version you linked, put it in a separate empty folder and ran it. It still gives me the same error. After getting the error again, I closed off some programs and tried again. Still the same error.
OK, thanks for your report. I almost sure this is error is caused by some kind of incompatibility with other software you have installed (or with your current Windows build). I don't know if there is a way you could generate a 'debugger dump' to help Rejetto catch and fix this error (and see why this error happened on your PC and not on others). Like bmartino1 said, as a reference it would be nice to know the exact build number of Windows 10 that you run (to do this: press Win+R, write there "winver"). For the moment, keep using that old version 2.3j (#298).

@Rejetto: is there any 'debugger' that this user could run to generate a 'dump'? I was thinking on WinDbg, but I don't if that software generates a crash report that could help you to fix this error. Since I bet this error is 90% related to the "Kryvich's Delphi Localizer" component you added on HFS 2.3 Build 300, I was thinking if there is a way to make a 'conditional' load of this component (a simple check when HFS starts: if the 'hfs.lng' file exist, then load the component normally, but if that file does NOT exist, then the component is not loaded at all, since it's not needed). Perhaps that could be a temporal solution to this (but I don't know if it's feasible to do that).

Bug reports / Re: HFS not able to start.
« on: October 12, 2018, 02:32:45 AM »
Hi! and welcome to the forum... :)

That's a weird error, since HFS it's not using "UTF8VCL" (although it seems to be related to "Kryvich's Delphi Localizer", but you are the first person to report a problem). Are you using some translated version of HFS? (like this version).

Please do this: try running HFS v2.3k Build #299 Spanish Beta and see if it gives you the same error or if it starts normally, but run it on a separate (different) folder (this is very important), without copying any personal file there (if you have another HFS version running, please close it before running this other version). Just unzip it to some folder, and run hfs.exe without adding or deleting any other file (and do not update it to the last version, just for doing this test). If the error continues, try closing any other software you have open (like for example: keynote-nf or any other software). Then please report the results here. ;)


Beta / Re: version 2.4
« on: October 08, 2018, 12:02:23 AM »

give it a try
I can't believe it! YOU DID IT!
I had forgotten how amazing you are! :D

Now it works great from Chrome v19.0 to Chrome v31.0 (and beyond).

I am again confronted with a reported problem: check boxes checked have the same effect as clicking the name of the associated item
Code: [Select]
.item-link { float:left; }
Code: [Select]
.item-link { float:none; }
...seems to solve the problem.

by changing "upload-panel" by "upload panel" he had thus transformed $('#upload-panel') into $('#upload panel') leaving <div id="upload-panel"
I did notice that when I was doing a comparison between 'Build 2' vs 'Build 3' with DiffNow, but I didn't say anything because it thought it was a proper fix. By the way, with the last edition, he deleted this line (I don't know is has any effect, because it seems to work OK without that):
Code: [Select]
<link rel="stylesheet" href="/?mode=section&id=icons.css" type="text/css">
do you think you can make a drop-down menu for the "more options" button instead of a central popup?
That could be nice, but (IMHO) only as an option for desktop browsers, because I think on small screen devices, that could lead to usability problems (like clicking by mistake outside the menu and having to start again). Perhaps this can be done using only CSS, but distinguishing between mobile vs desktop by its size is not easy nowadays, since new devices have big screen resolution. As an idea, maybe a new 'mobile' icon can be added (along with the 'lightbulb'), to switch between mobile and desktop, so in the default mobile theme we can have the current modalbox, and in the desktop theme the dropdown proposed by Mars. But that's in the case Rejetto is interested on this.

how to define  comments in Russian characters, store them, and restore them correctly to the web page

this comment как возможная функция
On my PC (using the Build 4), that comment gets stored and displayed as:
Code: [Select]
??? ????????? ???????
...and my browser can display russian characters without problems. Perhaps unicode comments could be stored on Base64 (using `atob()` and `btoa()`). Just an idea...

In the dark theme, the 'foldercomment' needs his own CSS code (new line to add marked in red, and I've used a slightly different color to not to be confused with a file comment):
body.dark-theme .item .comment { background-color:#444; color:#888; }
body.dark-theme #foldercomment { background-color:#333; color:#999; }

I did a quick test, and it seems all the comment problems I've reported, are solved now (that's great!). :)

Beta / Re: version 2.4
« on: October 06, 2018, 05:53:49 PM »
First of all, sorry for my misplaced comment :-[ (I felt bad yesterday, and I thought you will never notice my hidden comment). I'm glad to see that you are open minded and that you appreciate my time, and there is no hurry (take your time to make the decision). My initial worries were that you could have been using 'ECMAScript 6' on purpose, as part of the massive 'browser planned obsolescence' there is currently going on (but now after reading your comments I notice that I was wrong, so, sorry again for my comment). Feel free to take whatever decision you think is best. :)

What kind of use you make of your XP computer? Is it a media server? a secondary  computer? a primary computer?
One of them I used them a media server on WinXP (for local sharing files, offline), but I also have one WinXP online (with a firewall) as one of my primary computers (that PC is used as client of the offline PC), and then I have another much faster PC only for gaming and specific applications, loaded with Win7 (but it's mostly turned off, because it's too noisy to have it on 24/7, and mostly offline).

Does your template work well with that browser (Chrome 31) ?
It does! :D it works perfect not only with Chrome 31 but even with Chrome 19! (as well it works fine with Firefox 24, Firefox 31, K-Meleon Web Browser 75, and others I've tested). Of course it doesn't work with Firefox 3.x or IE6, but nobody use them nowadays.

don't rush, my dear  :) Opinions are mostly made by experience. Everybody's experience is limited and doesn't always produce the best of results. [...] I think it's the result of coming to conclusions too fast.
I agree, and it's something I work every day on being better. I'm somewhat "passional", in the meaning of sometimes I take decisions 'being carried away by feelings or thoughts, without rationally thinking about the consequences' (I took definition from the dictionary).

because older javascript is a boring Language. Even when i was using it i had made a function myself trying to emulate the => arrow functions.
That explains all! :) and it was my mistake thinking it was on purpose (part of the 'planned obsolescence' that is currently happening on many things). Sorry for my mistake.

I thank you for your hard work, i undertand it was very long, but the decision should not be made on the number of hours. Do you agree with this?
Absolutely! Feel free to take whatever decision you think is best. :)

I have a possible solution to all this: perhaps this could be fixed doing a small routine, that detects if the browser doesn't support "the => arrow functions" (or other 'ECMAScript 6' expressions), and then it 'dynamically translates' those functions/expressions with older JavaScript code. Doing this, you only do that routine once, and you don't have to change every function. What do you think?... :)

Beta / Re: version 2.4
« on: October 06, 2018, 03:56:47 AM »
@Mars/Anyone: Do you know why if you use the new template on the old HFS v2.3m, it doesn't work properly? (even using a modern browser). I don't see the reason why it could fail, since all the required files are self-contained on the template.

It gives the following error in the browser's console:

TypeError: newQ(...).on is not a function.
TypeError: $('body').on is not a function. (In '$('body').on', '$('body').on' is undefined)

I'm curious to know why it fails...

Beta / Re: version 2.4
« on: October 05, 2018, 07:25:29 AM »
why did you do this?  :o
i don't think it should support every browser.
what browser are you trying to support?
I use SRWare Iron 31 (Portable edition), because it's the fastest browser on Windows XP (other browsers are very slow and take a lot of resources). If you don't care about me, don't do this for me, but think that the same Chromium engine is used by default on many Android's browsers (Android 4.0.3 to 4.4), and not everybody have Android 6 to 8 with the latest browsers.

check it out!
I see you didn't used the most important parts of my changed template :'( (after all the time it took me to do it). I really can't understand why you insist on using 'ECMAScript 6'. For as much web developers try to make (aka 'force') people upgrade your browser, there are many situations (like old hardware) where it's impossible to always have the latest browser and operating system. On my case, Windows 7 is too slow for old hardware, and the support for new browsers on Windows XP is every day more limited.
> EDIT: I guess you don't care about users like me, the same as more and more people everyday care less for the others (we have the 'global warm' just because that attitude of 'not caring about his neighbor'). OK, don't worry, I accept you don't want to get rid of 'ECMAScript 6', after all you are the boss (è solo fa male l'atteggiamento). [Sorry, but I had a bad day, and now I come to the forum and find this, completing my bad day]
> EDIT2: @Rejetto: È così che mi ringrazi?! Mi sforzo, ti aiuto a segnalare errori e tu mi ignori in questo modo? Mi rende molto triste, veramente...

Bugs found on HFS v2.4 (using the default original template)

- Possible bug found #1: add a real folder, then on root set 'access' and 'delete' to anyone, then try to rename that folder trough the browser, and you will see that the folder it's now NOT shared anymore (the folder is renamed OK on the server's hard disk, but it's not updated on the HFS VFS).

- Possible bug found #2: add a real folder (with several sub-folders inside), give to those inside sub-folders a different comment to each folder. Now rename one of those folders, and the comment for that folder is gone (what really happens?: when HFS rename that folder, it doesn't update the folder name in the 'descript.ion' file, so the comment doesn't get displayed). The same happens if you rename a file that had a comment.

- Here is another different bug report about comments.

- Design issue?: if you give a comment to a folder, that comment gets displayed next to the folder path, without any design or indication that it's a comment. Here is a screenshot of what I'm talking about.

I'm attaching to this post an updated template, adding the changes from your latest template of HFS v2.4 Build 3 (hfs24b3.exe) [you can see here the differences from the template of Build 3], just in case you care about it.

Beta / Re: version 2.4
« on: October 04, 2018, 07:35:28 AM »
replace #menu-panel { position: fixed;
with      #menu-panel { position: -webkit-sticky; position: sticky; margin-bottom:5px;
Thanks for this DJ! I've added that in the template I've attached to this post (with some extra code to have a wide open browser support, as it's recommended here (I've used 0.3em instead of 5px as margin-bottom), as follows:

Code: [Select]
#menu-panel { position: -webkit-sticky; position: -moz-sticky; position: -ms-sticky; position: -o-sticky; position: sticky; margin-bottom:0.3em;
...and now: BIG NEWS! :)

After almost 5 hours of hard work (I'm not exaggerating), I did get rid of almost every incompatible JavaScript expression (ECMAScript 6), with the help of the tool (this tool lets you put in next-gen JavaScript, and get browser-compatible JavaScript out). It was a truly VERY painful job, because I've translated every function, one by one at hand, checking every line very carefully (just to be sure nothing goes wrong). So we now have a very compatible template that works beautifully! :D

I hope you like it (Rejetto: you can EASILY see and review all the changes HERE or using this online tool). Please report if something is not working.

jquery 1.12 seems to be enough for this template, so i'll try to embed that instead.
Remember that the latest stable version of HFS (v2.3m), used jQuery version 1.4.2 and not 1.12.

Another thing: you've used .on( method of jQuery, which was implemented on jQuery v1.7, so, before switching back to jQuery v1.4.2 you will either have to modify any function using it, or use this tiny polyfill (found here, not tested). Also the .split( method of jQuery may not be found on jQuery v1.4.2 (but I'm not sure about that).

Beta / Re: version 2.4
« on: September 24, 2018, 06:46:05 AM »
The new template looks awesome, congratulations! :)

And now, after several tests I did on this weekend, the reports...

- New jQuery version broke old browser support
I did quite a few tests, and I've found some problems. Since you have updated jQuery from v1.4.2 to v3.3.1, it's probable that you unintentionally have broke support to a wide range of 'not so old' browsers (remember not all Android phones have the latest browser installed), or you could have used some not wide-compatible code syntax too. I've tried several browsers, and the new template only work OK with the latest browser versions, but on most (two years old) browsers, all have the same problem: those new nice buttons doesn't get displayed at all, including the folder path which doesn't get displayed at all (the webfonts are OK). On a desktop browser, the console shows one 'Uncaught SyntaxError: Unexpected identifier' and two 'Unexpected token'. The most easy way to debug this, is to download a somewhat old version of a Chromium-based browser, like this: SRWare Iron Portable v31 (and here you can also find other versions if you want to do some more tests). Regardless, this new jQuery change gives also some unexpected results if an user wants to use an old template that depends on jQuery v1.X.X (I'll publish those results too, if you are interested).

- Small functional details
If you click on the 'Selection' > 'Mask' button, it will say 'Please enter the file mask to select: *', but there is NO button to accept it. If you are on a desktop browser, you can press the 'Enter' key, but on a mobile device an 'OK' button is needed. This also happens on the 'Move' button, that doesn't have a 'OK'. Another detail: the 'Selection' button is also ONLY displayed, for example, if there is a permission to delete in the current folder, but this is wrong, since if you also have the 'Archive' button visible, you need the 'Selection' button to being able to archive some files (without this, you will archive the whole folder).

- Offline use of 'Font Awesome' icons
Since HFS is often used on private LANs (without external internet connections), it would be best if the 'font-awesome.min.css' (along with the required WebFont files), are included inside the HFS executable (like the jQuery already is). Without that, if you use HFS offline, this new template doesn't work correctly.

- SVG vs WebFonts (or font optimization)
If you want to optimize this (since HFS barely uses 10 icons or less), it would be great if you only use the SVG/PNG format, instead of using the complete 'Font Awesome' WebFont. There are at least two sources of ready-to-use 'Font Awesome' icons in SVG/PNG format, here and here. You can also check this very interesting article describing why SVG is better than using icon WebFonts, but that decision is up to you. Another recommendation is to build a customized 'Font Awesome' version, leaving only the icons used by HFS (to reduce it's size), and you could do that easily on

Well, that's all... :)


Programmers corner / Adding Two-Factor Authentication (2FA) to HFS
« on: September 23, 2018, 01:16:24 AM »
Since HFS currently depends only on a primitive and weak HTTP/1.1 login system (where unless you use SSL, the password travels in clear text, encoded in Base64), I was thinking it would be nice if HFS implements a simple Two-Factor Authentication system (also known as TOTP or 2FA). This system is a time-based password algorithm (which change every 30 seconds), added on top of the current login. This way, if someone steals the user/pass, they could not get through the TOTP/2FA system (since the 2FA would prevent the access to your private account and files, even if they know the password).

- How this works on the server?
The server needs to generate a secret key (only once, when setting up the 2FA), and it would store that secret key (encoded in Base32) along with the user/pass (I'm always talking about the server part). At user/client level, when TOTP is enabled on HFS, it should check if the credentials (user/pass) are correct first, and then if they are valid it should ask for the 2-Factor Authentication Code. To make this work (like I've said), HFS should store (along with the username and password) the 2FA 'secret key' needed to generate the 2FA time-based codes. The rest of the work flow (at server level) can be read here. To end-users, I guess most of you know how the Two-Factor Authentication works, since Gmail already use it since several years (check out this, if have any doubts).

- Implementing TOTP on HFS using a free Delphi library
After a deep search, I've found a small Delphi/FreePascal/Lazarus library, that could make easy the implementation on HFS:

And now that version 2.4 is on beta test (and since HFS is doing a step from v2.3 to v2.4), I think is a great time to make the server a little more secure by default. I hope Rejetto like and welcome the idea, and if anyone here could collaborate at code level to make this works on HFS, it would be great :) (this is only a suggestion, not a petition to add it).


Programmers corner / Re: HTTP Header Size Problem
« on: September 02, 2018, 10:26:45 PM »
all the headers are not added in one block but at various stages of the execution, so it can happen that the one we want to withdraw at a given moment does not exist yet and that it appears at the end, the phenomenon is even more possible since some macros are not directly usable (especially in events)
That's right, I do understand, but from my point of view, I think [+request] is run first before anything (even before [+download]), so, perhaps the code to remove headers should be taken on consideration since the first initial request section. Correct me if I'm wrong.

You can try to reproduce the error using this or these 'HFS.Events'. More information about view HTTP Headers here.

HTML & templates / Some steps to reproduce the issue...
« on: September 02, 2018, 10:25:04 PM »
This, I tried for 3 hours with hfs 299-1/2 (the pre-release).  :) 
After upgrading to the official hfs 300, the remove headers command worked for cookies, not for etag.
That's why I've already reported this issue here. ;)

can you give some examples to reproduce in order to find a solution  ;)
You have several ways of view HTTP Headers:

1) The easiest way to reproduce this, is using Chrome. Open a new blank tab. Right click anywhere and select 'Inspect element' and then click on 'Network'. Close HFS and save the 'HFS.Events' file contained on the attached ZIP file in this post (or write in 'HFS.Events' any of these two filters described here). Open HFS, add some files (images or any other file), and go back to Chrome, paste the URL and watch the Network activity. To view the HTTP Header of any request, do right click on 'Copy response headers' on any element you want (and paste it on Notepad to view it). You will notice that any element generated by HFS on-the-fly will be fine, without the 'ETag', but if you request (click) on some file (to view it, or download it), then the 'ETag' is NOT removed (only Set-cookie is removed).

2) Another way is using FlаѕhGеt (being the version 1.65, the last adware-free version, which I'm currently using and you can download from here), or else using some HTTP Header view (online service), like this or this tool. If you use FlаѕhGеt, you need to configure it at the lowest possible speed (to being able to see the HTTP headers in the log), going to: Tools > Options > Connection > Traffic usage in manual mode (b/s): 400. And then go again to: Tools > Speed Limit Mode > Manual. And finally try to download (and quickly pausing it, to keep the logs at sight), a file that match some of those rules (as described on the point number one).

For example, a normal file listing request (it's working OK):

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 1890
Accept-Ranges: bytes
Server: HFS 2.3m
Cache-Control: no-cache, no-store, must-revalidate, max-age=-1
Content-Encoding: gzip
Content-Length: 1890

But viewing a static HTML file (the same as if you download other file):

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 123
Accept-Ranges: bytes
Server: HFS 2.3m
ETag: 6ED8C82CA55F6D57FECD5F712EFFF8F1
Last-Modified: Fri, 20 Apr 2018 20:30:40 GMT
Content-Disposition: filename="SomeWebPage.html";

Viewing/downloading a image file:

HTTP/1.1 200 OK
Content-Type: image/jpeg
Content-Length: 123456
Accept-Ranges: bytes
Server: HFS 2.3m
ETag: F48480F7C42C4CF548855994DF1B5191
Last-Modified: Fri, 20 Apr 2018 20:10:00 GMT
Content-Disposition: filename="SomeImageFile.jpg";

Summarizing: if you remove a header on [+download] it works, but on [+request] it doesn't do it properly (only removes 'Set-cookie' but not the 'ETag'). I personally don't need this feature, but since danny and User21 wanted it, perhaps it's a easy fix.

Well, that's it, I hope this is useful...

> Off-topic: This gives an idea that it would be great to have a HFS template that shows the response HTTP Headers of a given URL (perhaps using part of the remote upload code?), among other useful information, like the client's User Agent, screen resolution, etc (something like THIS). I leave the idea here if someone wants to do it. ;)

Pусский / Re: Вопросы по HFS
« on: August 29, 2018, 06:58:15 PM »
@falcon1598: Mars дает вам два варианта (вам нужно выбрать только один из них):

1) Одним из вариантов является добавление этого текста на "":
Code: [Select]
{.set ini|

2) Или другой вариант (достижение такого же эффекта), является оставьте это непроверенным.

Но вам нужно выбрать только один из них (что вам легче). Необходимо оставьте это проверено: «Auto-save options». Все остальное его объяснение касалось исходного кода (и некоторых технических деталей), только как ссылка.

HTML & templates / Re: No cookies for a certain folder?
« on: August 28, 2018, 06:12:45 PM »
I was wondering if it were possible, probably with, to have no cookies issued or attempted for a certain folder? 
Perhaps it is a folder of support graphics, such as wallpapers; or, perhaps HFS is pulling dual duty also supporting a wholly different website in addition to its normal duties.  Or, in my case, I need to do that for markup speed testing.
Make a "HFS.Events" file with any of the following content...

Option 1) This removes the cookie header, only when someone access some picture/graphics/photo, perhaps useful when someone hotlink to a image on your server (you can remove the 'add to log' line, since it's there for testing purposes only):
Code: [Select]
{.if |{.match|*.jpg;*.gif;*.png | %url%.}|{:
{.add to log|This file request was a photo!.}
{.remove header|Set-cookie.}
{.remove header|ETag.}

Option 2) This removes the cookie header, when someone access a folder that contains the name "FolderWithPhotosOne" or "FolderWithPhotosTwo" (you can remove the 'add to log' line, since it's there for testing purposes only, and perhaps this can be further enhanced to search and check if there are picture files on that folder, but that's way beyond my knowledge at the moment):
Code: [Select]
{.if |{.match|*FolderWithPhotosOne*;*FolderWithPhotosTwo*|%url%.}|{:
{.add to log|This folder request had cookie headers removed!.}
{.remove header|ETag.}
{.remove header|Set-cookie.}

I think the second option was what you were looking for...
Please report here if this solution works correctly. :)

Programmers corner / Re: HTTP Header Size Problem
« on: August 28, 2018, 05:24:03 PM »
Possible bug?... ???

This works:
{.remove header|ETag.}
{.remove header|Set-cookie.}

This partially work:
{.remove header|ETag.}
{.remove header|Set-cookie.}

It seems the "remove header" works perfectly on [+download] but on [+request] only remove the header "Set-cookie" but NOT the ETag. I haven't tested using another "Events" (perhaps this is a small detail to fix on the build).

Pусский / Re: Вопросы по HFS
« on: August 28, 2018, 03:35:54 PM »
Следуйте за этим:

1) Скачать и разархивируйте этот файл и поместите его в то же расположение hfs.exe.
2) На мгновение закройте сервер и откройте файл "HFS.Events" с текстовым редактором.
3) Измените IP "" на статический IP вашего посетителя.
4) Запустите сервер снова, и все готово.

Отныне ваш сервер будет реагировать ТОЛЬКО на статический IP вашего посетителя и будет ЗАПРЕЩАТЬ любой другой доступ с другого IP адреса. Пожалуйста, сообщите здесь, если это решение работает правильно.

Pages: [1] 2 3 ... 32