Messages

1

HFS ~ HTTP File Server / Re: opinions and requests

« on: February 03, 2009, 07:05:08 PM »

Rejetto,

I don't know if the folder size display would be worthwhile to other users or if it would make sense in terms of development effort.

I can handle that in another way, a real low-tech way.  Since my system is essentially static, I can have one small real folder for new files, while the rest of the system uses VFS.  For the top-level and secondary-level tables, I can manually check the properties of each folder and then (forgive me) type in the folder sizes by hand.  I can review and adjust those figures every year or two.

2

HFS ~ HTTP File Server / Re: opinions and requests

« on: January 28, 2009, 03:47:03 AM »

VFS refresh speed

Would it make a worthwhile difference in creating or refreshing a VFS to break the file system into smaller units?  We all have observed the major increase in folder refresh time in Windows when folders get above a few hundred items.  A few thousand items in each folder can slow a file system to a crawl, due to the nonlinear increase in time to sort larger sets.

This could be approached by breaking up large folders so they all have less than, say, 300 files and/or folders.

Another approach would involve multiple instances of HFS, each with a smaller VFS with only a segment or category of the contents.

It's easy enough to try it and see, but some of you may have tried it already and know the answer. 

3

HFS ~ HTTP File Server / Re: opinions and requests

« on: January 27, 2009, 08:36:50 PM »

Consider that many servers rely on external tools to perform advanced or time consuming operations (such as the one I work on professionally).  A batch script could offer you a lot of flexibility as well.  An exec macro could be incorporated to run the file size script whenever a file is uploaded to a folder, for instance.

I see your point (and Rejetto's) about external tools.   I have the impression that this process --- summing the file sizes for each folder (using code already in HFS) and storing them in a variable for display in the listing tables --- would be much faster and probably more stable using functions within HFS.   Presumably, repeatedly calling and running an external utility so many times would degrade HFS' speed and would open the possibility of other problems such as memory conflicts.  The key word is "Presumably."  My assumption may be wrong.  If so, then an external tool would be fine.

4

HFS ~ HTTP File Server / Re: opinions and requests

« on: January 27, 2009, 04:50:33 PM »

yes, i can work on such macro, but to not waste time on it, please first consider building a working mockup solution using a fake value.
i'll be happy to work on it when i'll be sure it is useful.

consider the other solution i linked

It would be clumsy to call external tools to do the data gathering job rather than using an HFS built-in function.  Further, as a newcomer to HFS, I still have lots to learn about how it works, and I also lack the free time to do this soon.  So a built-in foldersize variable would be useful.  It could read whole folder size (all files in each folder).

My purpose for it would be to display for users the rough size of each folder in a list.  Then, HFS (or a macro) could show the totals for each group of subfolders and perhaps the grand total for the whole system.

Others may well have very different needs.  I do not expect you to spend any time on it unless you decide that this would make HFS better.  Thank you for considering it.

 






   

5

HFS ~ HTTP File Server / Re: opinions and requests

« on: January 27, 2009, 02:04:34 PM »

I think many people wouldn't understand why the displayed folder size is WRONG (they not necessarily understand it's outdated).   
Doesn't seem something to be applied to everyone. So it should be something to be enabled on demand.

Yes, of course.  It would work best where major parts of the file system are static and the frequently changing parts are either refreshed frequently or in real folders.  Clearly, displayed folder sizes would be good for some but not for others' systems, so it should be an option.

Another problem is that the folder size is the total of the DISPLAYED files. Not necessarily all files are displayed, you can use filters, and other methods. Any change in this sense would invalidate the current value.

Yes, the current file-size logic could be applied to folders too.  Whatever selection criteria (filters, etc.) are in use for file sizes could be used in calculating folder sizes.  But if that's a problem, the total of all files in the folders could be used.  That would work quite well, as long as the labels shown to users make it clear whether it's a total of selected (filtered) files or of all files.

Consider that any geek can already do it for real folders at least www.rejetto.com/forum/?topic=6584

If you give us a symbol or macro that grabs folder sizes, we may be able to adjust our own templates to use it.  However, it would seem better and faster to buid into HFS the collection of folder sizes or selected folder sizes if that option is enabled.

6

HFS ~ HTTP File Server / Re: opinions and requests

« on: January 26, 2009, 04:06:05 AM »

Rejetto,

I've been continuing to explore HFS, grabbing a few minutes whenever possible to play with it.  The more I learn about HFS, the more I like it.  Upon reading the Template Macros descriptions, I am once again impressed by the amount of capability you've got stuffed into what I expected to be a simple web server. 

The power of systems like this, designed not for end users but those developing web sites, comes from giving developers maximum flexibility to accomplish what they want the way they want.  End users need "easy" while developers need "maximum control."

A web server is a conceptually simple tool: just read files on disk and serve up links to them.  But you have that task sitting on top of a system of high-level programming functions.  The result is extreme flexibility (power).   And for novices, you have a default system that can be used right out of the box.  With its extreme capability, it might be trivial to have HFS incorporate functions of an FTP server, a discussion forum, or many other web-interactive tasks.

HFS may not be fully cooked yet, as there are areas that could use more development, or documentation, or interface polish.  But in its current state, HFS is both powerful and usable.  It must be hard to overstate how much work goes into it.  As you must know all too well, as you add features, they interact in ways that can be unpredictable.  As you increase what HFS can do, the potential interactions among its components increase exponentially.   

Rejetto, please excuse my discourse, but I continue to be impressed by HFS.  It may be young, but it is already quite an accomplishment.  Nice going!

7

HFS ~ HTTP File Server / Re: opinions and requests

« on: January 24, 2009, 03:38:17 AM »

Further comment:  Selection of multiple files and folders is important, but showing the total size of each folder in a list of folders is not as important.  While showing the size of folders in a list of folders would be nice, users can simply go into a folder if they want to see the total size of its files.

8

HFS ~ HTTP File Server / Re: opinions and requests

« on: January 24, 2009, 03:25:03 AM »

Thanks.  BTW, my system's needs may not be the same as your other users.  My wishlist shouldn't count unless it reflects common need. 

we will never get the compression for folder archives. it's incompatible with the resume feature.

That makes sense (incompatibility with resume).  I see little need for compression.  How often do we download massive files that are not either compressed executables or compressed archives (zip, rar, etc) over a dialup connection? 

selection will come.

That's great!  If HFS will permit the selection of multiple files and folders to download, I'll marry it.

Even 15 seconds, to know the size of a SINGLE folder, is too much. It's just nothing you can know how long it takes. And you want to refresh the value every month? Showing a wrong (outdated) information . . .

In some cases that's consequential; in others it isn't.  My system has a static collection of files (classical music).  I could refresh a VFS as little as once a year.  New arrivals could then be kept in a real folder, or (better) in a VFS and that one small folder refreshed every night.

I agree that waiting even 15 seconds for the size of a single folder would be too much...if you were doing it in real time and sitting in front of a screen waiting for it to complete.  But if you schedule a VFS refresh to run during the night, or if you start the refresh before going to sleep, who cares how long it takes? 

If some HFS users have large file systems that change constantly, then (a) real folders can be used instead of VFS, and (b) perhaps HFS could offer the option of forming a VFS without adding foldersize.

9

HFS ~ HTTP File Server / Re: opinions and requests

« on: January 23, 2009, 03:30:59 PM »

JellyFrog and Rejetto, I like the idea of caching the foldersizes if VFS is used.  Because of my large folders (Each category has several hundred subfolders, with dozens of files in each.), real folders were used.  Your idea would make VFS worthwhile.  Then, the VFS could be refreshed once a month, while a small real folder could hold new arrivals.  Nice.

Rejetto, it would as you say "take minutes" to gather the total filesizes of folders and subfolders.  Many minutes for large sets.  HFS already takes a long time to form or refresh a VFS.  It's not a process you would sit there and wait for.  For small file systems, you would go get some coffee while HFS forms the VFS.  For medium systems. you would go out for the evening.  For large systems, you would go on vacation. :-)  In any case, since you're not sitting and waiting for it, taking more time to include foldersize should not be a problem.

Hmmm... Windows provides this information pretty quickly, taking only a few seconds for very large folders.  Can you use Windows' built-in calls to do this?

Yes, there are many utilities that handle Tar archives.  Haven't used 7-zip in a couple of years, but others like WinRAR, WinZip, etc. all work.  Also, many file managers, such as VCOM's Powerdesk, handle archives including Tar files directly.  The problem is a human one, not a technical one.   Now, non-techies will be faced with a Tar file for the first time, see something unfamiliar that may require who-knows-what from them, and get off the train at that point.  Many will not willingly learn what clicking the Archive link in HFS does.  Also, Archiving does not permit selection of some but not all files.

Ideally, HFS should be at least as easy for users as an FTP server with respect to selecting multiple files or whole folders to download.

Thanks for the link to HFS templates and symbols.  The total-size, total-kbytes, and total bytes variables (symbols) would seem relevant.  Perhaps they could be expanded to hold foldersizes as well as filesizes.   Or new, similar variables could handle foldersizes.

Rejetto, Zip is certainly more familiar to the broad range of users than Tar, but it would still leave the problem of requiring an archiving step and an unpacking step. If those two steps could be made transparent to users, then it wouldn't matter what archive format you chose.  Even small, fast ones with only moderate compression, like the old LZH (free) could be used.  You would have to include the small unpacking code in your transmitted pages though.

The compression that archivers provide isn't very important since many files are already compressed, so an archiver isn't really needed.  It's the selection capability (multiple files, whole folders) that's needed. 

10

HFS ~ HTTP File Server / opinions and requests

« on: January 23, 2009, 03:07:43 AM »

Initial thoughts about HFS from a very new user:

I was looking for a simple web server for occasional file transfers.  Instead, I found HFS which goes far beyond that.  Its capability and extreme flexibility are impressive.  I can imagine the effort that goes into making increasingly complex systems like HFS work well.

What I would I like to see in HFS: 

1.  Transfers of multiple files and whole folders.  I sought a web server for file transfers because some of my users are non-techies who found the existing FTP server too challenging.   Yes, the Tar archiving in HFS works, but these users, even though otherwise intelligent, would run for the hills at the mention of a Tar archive or of learning any new procedure however slight.  HFS is very good for downloads of one or two files, even very large ones.  But for downloading whole folders, each with a set of many related files, HFS seems to fall short.

2. Related to the above, drag-and-drop downloading would be nice (if HFS doesn't already do that) but not really necessary.

3. In the tables, I have no need to show the number of hits for each file or folder, which can easily be omitted from the tables.  Instead, it would be most useful to show the listed folders with each folder's size (total number of bytes in all files within that folder) and its number of files.  That way, users can see instantly whether particular folders are massive or tiny.

HFS is a well-crafted and promising product, and that's what keeps me playing with it.  I would very much like to adopt it.  It would be a pleasure to learn that the above functions are already in HFS or in an external template.

11

Everything else / Re: forum keeps asking for new activation code

« on: January 23, 2009, 02:29:06 AM »

Rejetto,

Thanks for your helpfulness in re-activating my account and in explaining the problem.  For a while, I thought I'd have to legally change my name from Matt to Matt2 :-)

I'll find a suitable topic to post some initial thoughts about HFS.   Thanks again.