opinions and requests

[Matt]

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.

[rejetto]

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

[Matt]

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.

 






   

[Unknown8063]

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

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.

[Matt]

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.

[luca69]

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

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.

This would not work if a file is added directly on the server 

[Unknown8063]

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

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.

This would not work if a file is added directly on the server 

Very true, but HFS couldn't detect that either.  HFS doesn't know what's in a real folder until the user requests the contents.

[Matt]

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. 

[rejetto]

It would be clumsy to call external tools to do the data gathering job rather than using an HFS built-in function. 

that's not what i meant with "fake value". it may just be a number you type in instead of the call.

[Matt]

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.