63 replies to this topic

[allanf]

The dots are back. Can't thank you enough for your time.

Reminds of a Pizza Joint jingle: 'I got the hots for what's in the box with the dots.... Domino's!'

Regards

[Arvy]

Thank YOU for YOUR time. As any developer will affirm, it's virtually impossible to anticipate and test all of the conditions that may arise in actual use. So your "bug reports" and other feedback are invaluable. Clearly, I also need to improve the user manual and the explanations it provides.

[Galapo]

Hi Arvy,

I've finally had a play with your work here and I'm now using it with LiveXP to compress the project into a single file to supply a link for the download section at winbuilder.net. This is exceedingly helpful and much better for me than uploading a complete project file from my local system due to my slow internet connection.

Regards,
Galapo.

[Galapo]

I've finally had a play with your work here and I'm now using it with LiveXP to compress the project into a single file to supply a link for the download section at winbuilder.net.

I downloaded the compressed project file and discovered the generated .tar image was corrupted. Further attempts at compressing to this file type also results in corrupted images. I then tried .zip and .gzip. Both also have issues on extraction because the folders aren't represented in the image correctly. .bzip doesn't even create an image, just results in a .bzip.tmp file.

Maybe there's an update for the compression library which fixes these issues?

Thanks,
Galapo.

[Galapo]

Contra to what I indicated above, the issue doesn't seem to be with the pclzip compression library. Rather, it seems likely to be more something in the wbfm.php file. That is, slightly incorrect data representation is passed for compression. In the resultant .zip file, for example, compressed directories are given a folder as well as a file name. This creates extraction errors.

Problem is I don't know php to issue a fix...

Regards,
Galapo.

[Galapo]

Gday Arvy,

Just wondering if there's any news on if or when the compression bug may be fixed?

Much thanks,
Galapo.

[Galapo]

Bump!

Sorry, I hate sounding impatient, but still curious about a fix for the issue raised above.

Thanks,
Galapo.

[Arvy]

Hi Galapo.

First, my humble and profound apologies to you and others for my long absence. It is my habit to spend the summer months engaged almost exclusively in outdoor activities enjoying Canada's scenic diversions, so that any computing projects tend to get badly neglected during that time.

I've had a cursory glance at the compression issue that you mentioned and there clearly is a problem as you suggest. It does indeed seem to originate somewhere within the data that is being passed to the library by the file management process, but the specifics will require further investigation. I'll get on it as soon as I've finished "resettling" myself here at home and I'll pass along a solution as soon as I possibly can. In the meantime, I'll do my best to update this thread in a more timely fashion regarding progress or otherwise.

[pscEx]

Hi Galapo.

First, my humble and profound apologies to you and others for my long absence. It is my habit to spend the summer months engaged almost exclusively in outdoor activities enjoying Canada's scenic diversions, so that any computing projects tend to get badly neglected during that time.

I've had a cursory glance at the compression issue that you mentioned and there clearly is a problem as you suggest. It does indeed seem to originate somewhere within the data that is being passed to the library by the file management process, but the specifics will require further investigation. I'll get on it as soon as I've finished "resettling" myself here at home and I'll pass along a solution as soon as I possibly can. In the meantime, I'll do my best to update this thread in a more timely fashion regarding progress or otherwise.

Hi Arvy!

Glad to see you again.

I use your solution regularly and find it much more comfortable than the WinBuilder basis solution.

But like Galapo I have some wishes / suggestions etc. I forgot in the long time of your absence.

But I'll remember and put here ...

Peter

[Galapo]

Gday Arvy,

I was hoping you were alright, so I'm glad to hear that you were just having a holiday. Actually, I'm a bit envious! But I have to keep plugging away at my thesis...

Anyway, thanks for looking into the issue I raised. Hopefully the bug isn't too difficult to catch and fix. In the meantime I've just been using putty to gain access to shell functions so that I can use zip to create archives directly on the server instead of having to upload. But I prefer using your package for other tasks, so it'll be good to do everything there once compression is working.

Thanks again for your hard work in providing such a complete and easy server management system. I like and appreciate it a lot!

Regards,
Galapo.

[Arvy]

Gday, Galapo.

No worries. I'm fine, although somewhat exhausted after a week-long horseback trip in the Rockies (Jasper). I guess I should have done that nearer the beginning of the summer rather than at the end. Oh well, there'll be plenty of time to sit around here at home during our sub-Arctic winter months.

It appears that the compression problem you noticed is buried quite deep in the file management code that I "borrowed" for use with my WinBuilder DBMS package. I chose it because of its veratility, but it's an old one that is no longer being developed by its original author. In the circumstances, I'm not sure if it's really worth spending a lot of time trying to "debug" it or not. It might be both easier and more beneficial to end users to just dump it and substitute a file managment tool that's more current.

I've found one at http://extplorer.sourceforge.net/ that looks quite interesting. It includes all of the PHP file management features of the old one and adds many of those that are found in FTP packages like Net2FTP. Nuno Brito would probably disapprove of its reliance on javascript capable browsers, but almost everything does these days and it's unlikely that the DBMS consolidation concept will be adopted for WinBuilder in any case. It's just my own experimental plaything.

What's your opinion? Should I keep trying to debug this old one, or switch to something newer with ongoing dev support and more sophisticated file mangement features?

[pscEx]

Nuno Brito would probably disapprove of its reliance on javascript capable browsers, but almost everything does these days and Nuno seems fundamentally opposed to the whole DBMS consolidation concept in any case.

What's your opinion? Should I keep trying to debug this old one, or switch to something newer with ongoing dev support and more sophisticated file mangement features?

You did not ask for my opinion, but it is the same one you assume Nuno to have:
Hold WinBuilder support in a level that can be used by every browser w/o having special 'options' / 'plugins' etc. selected.

BTW: in my Firefox 'NoScript' is working. And when I com onto a page requiring e.g. JavaScript > forget

Peter

[Arvy]

You did not ask for my opinion, ...

Anyone who has spent more than five minutes here and who isn't already aware of your minimalist philosophy and opinions just hasn't been paying attention. This entire experimental project, from its very conception with multiple PHP scripts, common library depenencies, SQL RDBMS, etc., runs counter to almost all of them. I'm surprised you're even looking at it.

As for javascript in particular, its just one more scripting language amongst many and, in fact, it probably carries less potential for "evildoing" on local boxes than quite a few others, including at least some of those that run under WinBuilder itself. Nevertheless, you are certainly entitled to whatever restrictions you see fit to impose on yourself. I'm sure you will undertand, however, if others, including myself, continue to apply less rigidly puritannical parameters in our own admittedly "radical" pursuits, even if they won't run on the original DARPAnet or the usenet protocol either.

[Galapo]

Hi Arvy,

Wow, I'm even more envious! I grew up riding horses on my parents' farm, so I enjoy it a lot although don't get to do it very often now at all. But I know what it's like to not ride for a while, so I imagine a week-long ride would make one quite sore. My wife worked in Canada for a couple of years and has told me about the Rockies.

Now, regarding our current issue. I'm not sure what to say other than offer a few thoughts. First, the compression bug would seem to relate to parameters passed to the compression library since in any given archive containing folders and files, there is more than one representation in the archive. So when it is extracted, overwriting with null data occurs.

Second, I am happy with the current features offered, so if this bug could be found and fixed relatively easily, then that could be the better option given Peter's view above. But that I guess depends on the balance between the time to find and fix and the time to implement an eXtplorer-based package.

Third, while I like Peter use NoScript in Firefox, I reguarly find myself making exceptions for some websites, so I personally don't have an issue with moving towards eXtplorer. (As an aside, I have NoScript disabling some stuff on boot-land as it is, so Nuno would seem to be open to making some script exceptions.)

Fourth, eXtplorer looks really good! I like the option of net2ftp.

Hope this helps!

Regards,
Galapo.

[Arvy]

Well, except for my own demo testing, you and allanf are the only people with site projects that are actually registered under the DBMS system. So your comments carry considerable weight.

For now, I'll keep looking for the culprit in the existing file manager code and trying to pin it down. Your analysis of the bug's effects corresponds with my own. If I'm not successful within a reasonable time, however, it may be worth looking more closely at the alternative option. I would expect that it probably only uses javascript for a few "bells and whistles" that wouldn't be a major loss for those who might choose a "NoScript" browser setting anyhow.

__
P.S.: If you ever decide to try a week-long horseback excursion in the Rockies or elsewhere, make sure that the trail boss brings along a good camp cook.

[Arvy]

Hi Galapo.

It appears that my recollection of certain details of this project and its beta status issues is slowly returning after a long break. I remember now that the file manager's compression feature was giving me some similar problems earlier and that I had created an alternate solution prior to my departure in order to deal with it on an interim basis.

If you will log on to your http://livexp.boot-l...net/WBDBClient/ location as its administrator, and click on one of its project folders (either LiveXP or Tools) under the main Client Ops tab, you should see several buttons near the bottom of the project listing: "File Manager", "Compress", "Create INI", "Update dB". Clicking the "Compress" button and then the confirmation to "Compress Project" should give you a properly ZIPped file that will be located in your Compressed folder. If you choose the Tools project folder, for example, you should end up with a \Compressed\Tools.zip file without any of those glitches that occur when the file manager is used for the same purpose.

The problem with that old file manager appears to lie somewhere within its use of Kevin Doucette's archive (TAR/GZIP/BZIP2/ZIP) classes, but I still haven't been able to pin it down more precisely. It may be that the classes themselves have simply fallen behind PHP's recent development curve. I'll keep trying, but we may be forced to look at someting more up-to-date. In the meantime, at least you have that alternative option for automated project compression that should work correctly. Let me know, please.

BTW, you might find it preferable to relocate your WBDBClient folder outside the folder that contains your actual WinBulder projects subfolders if your site structure allows you to do that. If not, don't worry about it. Just don't modify the WBDBClient folder contents by mistake.

__
P.S.: If you'd like to take an exploratory glance at the eXtplorer file manager's features, go to http://virtech.org/winbuilder/fileman/ and log on with username "fileman" password "fileman".

[Galapo]

Hi Arvy,

Thanks for your work on this.

For some reason, I see no "Compress" button: only "File Manager", "Create INI", and "Update dB". Is there a newer package version to download with this feature?

Currently, the WBDBClient folder is located where it is so that the project folder doesn't have to be relocated. My main reason for doing this is so that links posted to date on boot-land will still function; but at some point the advantages to adjust will have me doing so I think.

I've uploaded eXtplorer to my galapo.boot-land site to test and have found so far that it is very good.

Regards,
Galapo.

[Arvy]

For some reason, I see no "Compress" button: only "File Manager", "Create INI", and "Update dB". Is there a newer package version to download with this feature?

That's strange. There is no download package that is newer than the one you downloaded. When you log in to your own site as the administrator and click on either one of your project folders, the "Compress" button should be there with those others you are seeing under the project listing.

I've double checked on my own test setup and all appears okay. And I've also double checked the DBMS entries for your setup. Without your private password, I'm not able to try it directly on your site, but there's no logical reason I can think of why it would behave differently there. For now, I can only suggest clicking your browser's refresh button a time or two. I'll give it some further thought overnight and get back to you.

[Galapo]

Hi Arvy,

Sorry, I was incorrectly assuming that it was a dedicated button.

When browsing Local/ it doesn't appear.
When browsing Local/Tools/ it appears.
When browsing Local/LiveXP/ it appears.
I have another folder /Local/Compressed/ and it doesn't appear.

Regards,
Galapo.

[Galapo]

Compression with eXtplorer isn't that appealing as it is.

For example, I tested compressing a folder \api\ at my galapo.boot-land address. Instead of compressing files under \api\ to a folder named "api" in the archive, it compressed to the following named path in the archive: .\\home\.fluke\galapo\galapo.boot-land.net\api\'. This is not nice for proving an archive of, say, a WP project directory to be downloaded my end users. Extraction on an end users system would be to 'home\.fluke\galapo\galapo.boot-land.net\api'. Not desirable, in my opinion.

Regards,
Galapo.

[Arvy]

When browsing Local/ it doesn't appear.
When browsing Local/Tools/ it appears.
When browsing Local/LiveXP/ it appears.
I have another folder /Local/Compressed/ and it doesn't appear.

As Mickeysoft would say, that's a feature, not a bug. The "Compress" button is currently designed to show up only for actual project foldlers and not others. But that could be changed, of course, if clients want it to be.

Compression with eXtplorer isn't that appealing as it is.

Thanks for checking it out. I hadn't yet looked at it beyond a very quick glance. Now that I've looked a bit deeper, it also appears to use much more javascript than I expected for its basic features. So, if we are forced to replace the old file manager with something newer, we'll have to look elsewhere. There are certainly plenty of other PHP-based file managers to chose from. Hotscripts, for example, has a multi-page listing. There's even a file manager PHP class.

[Galapo]

As Mickeysoft would say, that's a feature, not a bug. The "Compress" button is currently designed to show up only for actual project foldlers and not others. But that could be changed, of course, if clients want it to be.

Here's my thoughts: the "compress" button is not needed outside project folders IF file manager compress is working. However, in it's absense, wider use of "compress" button is desirable on my end.

Yes, eXtplorer makes wide use of javascript, right from logon it seems. Not really an issue if that doesn't concern users (it doesn't concern me, as it's my site, I'm responsible for it, and I'm the sole one making use of eXtplorer if it's there). If only the compress function would strip away most of the path!

Regards,
Galapo.

[Arvy]

Well, here's a report on "progress" of sorts.

In an effort to pursue a "logical troubleshooting" approach, I've been testing various permutations and combinations, but the inconsistency just keeps getting stranger. It appears that the file manager's TAR, GZIP and BZIP compression of project folders and their contents are all working just fine. They contain none of those zero-byte "ghost entries" that we've seen in the ZIP compression results. Even more strangely, however, the ZIP compression problem only seems to show up when the file manager is running on a *nix server. When I run it on a Windows 2003/IIS server it creates ZIP compressed files that appear perfectly okay when downloaded and opened by my archiver utility.

I haven't reached the stage of tearing my hair out yet, but I sure am baffled by this one so far. If anyone has any brilliant ideas, I'd be more than happy to hear them.

Incidentally, there's no question of anyone other than administrators of client sites having any access to or using whatever file manager application we may ultimately decide upon. So that is definitely not an issue of any concern. Ordinary vistors to any client site see nothing but the output of server-side PHP scripts and SQL dB queries. For them, there is absolutely no javascript or other type of client-side scripting involved at all. In fact, non-admin vistors have no direct file access whatever except via the completely ordinary HTTP download links that are provided in the results of their DBMS searches.

[Arvy]

Well, Galapo, I hate to admit defeat, but this one seems to have me stymied. I've reluctantly reached the conclusion that it's just not worth any more effort and frustration trying to make that old file manager and its built-in compression classes handle ZIP file creation properly on all types of platforms where it might be installed by DBMS project clients.

With your particular projects account located on the boot-land/winbuilder.net server, the problems with conducting a proper investigation are further complicated by numerous "Internal Server Error" issues and by the fact that, for some unknown reason, the ZIP extension for that server's PHP installation is not enabled at all! In the circumstances, it's almost impossible to determine with certainty whether the compression errors we are seeing originate as a "bug" in the file manager, or in the server setup itself, or partly both. So being able to find an appropriate corrective measure to suit such circumstances appears to be a very remote likelihood.

I have been able to find another file management utility that might be more acceptable to you and Nuno and other members of the WinBuilder development team. The Invision Power File Manager (v2.0) was created by the same folks who developed this WinBuilder forums board that we all use here and, like the Invision board, it only uses javascript for such very minor chores as validating user inputs to registration and login forms. Unlike this board, however, Invision's file manager has been released by its authors for public use with permission to "customize the software's design and operation to suit the internal needs of your web site" and to "create applications which interface with the operation of the software."

Based on my own testing to date, it appears to work properly on both *nix and Windoze platforms, with the exception that it cannot, of course, overcome the winbuilder.net server's lack of PHP support for extracting the contents of ZIP-compressed archives on the server itself. That would require changes to the server's PHP configuration that only Nuno could implement.

For Galapo and anyone else who might wish to comment on the Invision file manager's suitability or otherwise, I've installed a standlone copy (i.e., not yet linked into the main WB DBMS project) at http://browser.winbu...client/fileman/ for testing purposes. Logging in there with username "fileman" and password "fileman" will take you directly to the test site's WinBuilder projects folder where you can feel free to experiment with any and all of its features and capabilities. Or, if you'd like to test it on your own account, let me know and I'll set it up for you.

__
P.S.: The previous eXtplorer test setup has been removed as we appear to be agreed that it is not suitable for our purposes.

[Galapo]

Hi Arvy,

Thanks indeed for your dedicated attempts as sorting out the issue! Personally, I'm happy with whatever you decide: it's your time your devoting.

I've just given the Invision File Manager a test (made difficult due to the repeated "Internal Server Error" messages) and find it to work fine. The interface isn't that great, but I assume if you choose to adopt this file manager, you'be using their code but keeping the past (preferrable) interface.

Thanks again for trying to sort this out.

Regards,
Galapo.