rejetto forum

Software => HFS ~ HTTP File Server => Beta => Topic started by: rejetto on August 08, 2010, 07:19:33 PM

Title: Testing build #266
Post by: rejetto on August 08, 2010, 07:19:33 PM
download @ www.melauto.it/rejetto/hfs266.exe

what's new
+ {.get|can delete|path=XXX.}
- fixed more problems with non-ansi characters in filenames
- browser cache support for embedded icons disabled until a fix is found
Title: Re: Testing build #266
Post by: suriyothai on August 08, 2010, 07:41:49 PM
Version 266 no trojan message. until now

Lothar
Title: Re: Testing build #266
Post by: SilentPliz on August 09, 2010, 03:08:47 AM
I just Noticed that the ini.bak file no longer seemed created , during the backup options.
The vfs.bak on quit as well.
Title: Re: Testing build #266
Post by: suriyothai on August 09, 2010, 09:48:27 AM
Hallo my dear Frend rejetto

please send me the Version 265 with E-mail i have G-Data on the line an there will look and work it .

i can`t download it..... the website are closed from G-Data

Thanks a lot

Lothar
Title: Re: Testing build #266
Post by: rejetto on August 09, 2010, 11:06:23 AM
i use gmail and cannot send an exe file via email, sorry.
i doubt g-data is blocking only the web.
i bet it will stop you also via email.
my advice is to learn how to make exceptions, or change for a software that has this feature.
Title: Re: Testing build #266
Post by: rejetto on August 09, 2010, 11:09:11 AM
I just Noticed that the ini.bak file no longer seemed created , during the backup options.
The vfs.bak on quit as well.

.bak files were always created for VFS only, never .ini
Title: Re: Testing build #266
Post by: rejetto on August 09, 2010, 11:11:54 AM
OT, simbadda moved to http://www.rejetto.com/forum/index.php/topic,8985.0.html
Title: Re: Testing build #266
Post by: SilentPliz on August 09, 2010, 11:21:49 AM
...never .ini
I had to dream this option ... a moonless night ::). :P
Sorry.
Title: Re: Testing build #266
Post by: suriyothai on August 09, 2010, 11:29:22 AM
i use gmail and cannot send an exe file via email, sorry.
i doubt g-data is blocking only the web.
i bet it will stop you also via email.
my advice is to learn how to make exceptions, or change for a software that has this feature.

ok..

then you can send it to my server in to the folder upload

Title: Re: Testing build #266
Post by: suriyothai on August 09, 2010, 12:26:59 PM
oh the version 266 is ok ..i need the version 265 to send it g.Data
Title: Re: Testing build #266
Post by: suriyothai on August 09, 2010, 12:39:14 PM
oh the version 266 is ok ..i need the version 265 to send it g.Data

OK thanks a lot now i will send it G-Data
Title: Re: Testing build #266
Post by: CivicScootin on August 10, 2010, 03:53:00 AM
Working great on my end so far!..
Still wish there was "MOVE FOLDER/FILE" option with in browser so my Admins can move there own files with out myself having to..
First Beta build I have ever used..
Very good ~ Keep up the great work
Title: Re: Testing build #266
Post by: Nocturnus on August 10, 2010, 08:20:24 AM
The new beta seems to be ok but the download link is down

(http://i38.tinypic.com/hspbfd.png)

Title: Re: Testing build #266
Post by: suriyothai on August 10, 2010, 09:51:06 AM
OK thanks a lot now i will send it G-Data

Now the answer

Dear G Data Customer,

Thank you for your inquiry.

In the described virus is detected by our software is an error code (so it's no virus on your system). This (incorrect) detection by our software has already been reported and is now fixed.
Title: Re: Testing build #266
Post by: CivicScootin on August 11, 2010, 03:37:10 AM
The new beta seems to be ok but the download link is down

Links now back up
Title: Re: Testing build #266
Post by: simbadda on August 11, 2010, 06:32:42 AM
Hello, I think I have found a bug with folder creation.  I have used the "Bind root to real-folder" feature.  When a user tries to create a new folder using the HTTP interface in the root directory, the folder actually gets created in the parent directory of the root.  To the user it looks like nothing has been accomplished because he cannot see the root's parent directory from the HTTP interface.  The "New Folder" feature seems to work fine in subfolders, just not in the root folder.
Title: Re: Testing build #266
Post by: CivicScootin on August 11, 2010, 09:00:30 PM
I do not believe any users but the sever holder could create a new folder with in the ROOT of the server..
If you look within the PROPERTIES - PERMISSIONS TAB you will notice that only ACCESS & DELETE are shown..
UPLOAD is not found at all..

I believe this was set like this from the main build..
I could be wrong as I never used a beta besides this build however I really think the only way to make a folder (or to upload anything) to the ROOT is done by the server controller only..

If Im wrong please correct me ya'll

In short I have the same issue~
Title: Re: Testing build #266
Post by: SilentPliz on August 11, 2010, 09:25:09 PM
The "New Folder" feature seems to work fine in subfolders, just not in the root folder.

New folders must be created in a real folder, by a user having permissions for Access and Upload on this folder... not in root.
Title: Re: Testing build #266
Post by: simbadda on August 11, 2010, 11:18:46 PM
New folders must be created in a real folder, by a user having permissions for Access and Upload on this folder... not in root.

But the root is bound to a real folder, so a user should be able to create a new folder in it.

For example:
I choose "Bind root to real-folder" and choose C:\Files\HFS as the "root"
I browse to HFS in my browser and choose "New Folder".  If I do this, the folder gets created in C:\Files, not C:\Files\HFS -- I think this is a bug.
If I choose "New Folder" while I am looking at C:\Files\HFS\Subfolder, the new folder gets created in the correct folder.

Thus the software is allowing me to create a new folder when I am in root.  It's just creating it in the wrong directory. 
Title: Re: Testing build #266
Post by: SilentPliz on August 12, 2010, 12:35:25 AM
Edit: I first wrote the message below ... but actually you're right, it seem to be a bug.
You can create folders in / .... these folders are visible but inaccessible in the root ... and they are visible and accessible (really created) in /HFS/

I precise: for my test c:\file\HFS is not the folder of hfs.exe... just a folder like as your example.

I have succeeded to reproduce this bug with an old template, but not with the default tpl. With the default tpl, folders are created in the hfs.exe folder (same bug but another manifestation of it).
By cons HFS would display the three tabs: Acces Upload and Delete in the properties of /root, in both case.


Its not a bug.

Example:

If I link (bind to root) a folder named "/myfolder" to the root, this folder and its entire contents (subfolders and files) is "unfolded" to the root, but still belongs to /myfolder.

So a user which has permission to create subfolders in /myfolders, can create folders and subfolders in /myfolders and in all its content, although apparently this content seem to belong only to the root.

/root
    myfolder  (bind to root) > user can create new folder in it
    aaa        (subfolder of myfolder) > user can create new folder in it
    bbb        (subfolder of myfolder) > user can create new folder in it
    file.xxx    (file in myfolder)


aaa and bbb aren't created in / but are created in:
/myfolder/aaa
/myfolder/bbb


A user with rights on myfolder, therefore has the same rights on all reals folders of this folder even "linked to root".
Title: Re: Testing build #266
Post by: simbadda on August 12, 2010, 05:09:33 AM
SP, yes you're right, the bug is a little different than I reported.  So the bug is that if a real folder is bound to the root, when the user attempts to create a new folder in that folder, the folder is actually created wherever the hfs executable resides, not the bound root folder.

I have succeeded to reproduce this bug with an old template, but not with the new.

Where can I get the new template?  I am using the latest build, 266.
Title: Re: Testing build #266
Post by: SilentPliz on August 12, 2010, 07:51:21 AM
Replace this:

      {.if|{.can mkdir.}|
      <button onclick='ezprompt(this.innerHTML, {type:"text"}, function(s){
            $.post("?mode=section&id=ajax.mkdir", {"name":s}, getStdAjaxCB());
          });'>{.!New folder.}</button>
      .}


by this:
      
     {.if|{.%folder% != / .}|
      {.if|{.can mkdir.}|
      <button onclick='ezprompt(this.innerHTML, {type:"text"}, function(s){
            $.post("?mode=section&id=ajax.mkdir", {"name":s}, getStdAjaxCB());
          });'>{.!New folder.}</button>
      .}.}


Seem correct the bug (workaround only).
Title: Re: Testing build #266
Post by: rejetto on August 12, 2010, 05:42:13 PM
root bug fixed in next release (267)

note: the problem is in the prorgam not in the template
Title: Re: Testing build #266
Post by: SilentPliz on August 13, 2010, 03:34:25 AM
@simbadda

Quote from: simbadda

I have succeeded to reproduce this bug with an old template, but not with the new.

Where can I get the new template?  I am using the latest build, 266.

I used an "old" template with the latest build 266. Don't worry, you haven't missed anything new. :) ;)
Title: Re: Testing build #266
Post by: CivicScootin on August 14, 2010, 04:41:11 AM
root bug fixed in next release (267)

note: the problem is in the prorgam not in the template
Good to know thanks for the statement
Title: Re: Testing build #266
Post by: SilentPliz on August 20, 2010, 01:24:57 PM
Hi! :)

Usernames with accented characters are badly displayed in browsers.

(http://img121.imageshack.us/img121/1710/userinfoo.png) (http://img121.imageshack.us/i/userinfoo.png/)

   <fieldset id='login'>
      <legend><img src="/~img27"> {.!User.}</legend>
      <center>
      {.if| %user% |{:
            {.convert|ansi|utf-8|%user%.}
            {.if|{.can change pwd.} |
                <button onclick='changePwd.call(this)' style='font-size:x-small;'>{.!Change password.}</button>
            .}
            :}
            | <a href="~login">Login</a>
        .}
      </center>
   </fieldset>
Title: Re: Testing build #266
Post by: rejetto on August 26, 2010, 08:59:02 AM
thanks for reporting the bug SP.
sadly, your fix is not good, as it must comply with the rest and be encoded by HFS itself, not the template, as for other symbols.
fixed in next release
Title: Re: Testing build #266
Post by: Murdock on August 26, 2010, 02:15:52 PM
Rejetto,

When do you think to relaese a new final version?
Title: Re: Testing build #266
Post by: rejetto on August 27, 2010, 12:42:35 PM
soon, after i read all the messages of the latest days