Testing build #266

[simbadda]

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.

[CivicScootin]

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~

[SilentPliz]

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.

[simbadda]

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. 

[SilentPliz]

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".

[simbadda]

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.

[SilentPliz]

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).

[rejetto]

root bug fixed in next release (267)

note: the problem is in the prorgam not in the template

[SilentPliz]

@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.

[CivicScootin]

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

[SilentPliz]

Hi!

Usernames with accented characters are badly displayed in browsers.



   <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>

[rejetto]

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

[Murdock]

Rejetto,

When do you think to relaese a new final version?

[rejetto]

soon, after i read all the messages of the latest days