using saveas dialog on a window base workstation, displaying the UNIX directory tree

[Deanna Helie]

I have a cross platform software application. The frontend is Powerbuilder and it runs on the user's workstation. The backend (processing), applications and data are located on a UNIX server. I am using RPC logic to handshake and communication between the two ends. The user enters a request on the workstation, the data stream is passed to the session that is connected via RPC,a program processes the request and the result data stream is passed back to the user via RPC for display.

You can use the same frontend to talk to various backends.

One feature is saving a file that they are viewing. If the user is running front-end WIN and backend WIN server, I can use the WIN API saveas function and can save the viewed file on their WIN server; but for the UNIX users, the file that they are viewing in located on the UNIX server,so if they wish to save the file to another directory on UNIX or rename it and save it a directory on UNIX, they can't.
I was think of using the tree command on UNIX and then pass this to the WIN server but I am leaning towards the way the graphical FTP environment does the display of directories on a server.

any suggestions??

[Steven Schweda]

Has it really been a year since this all
started? How time flies...

http://forums.itrc.hp.com/service/forums/questionanswer.do?threadId=1275654
http://forums.itrc.hp.com/service/forums/questionanswer.do?threadId=1357939

[OldSchool]

gee... according to this (last year), you'd solved this issue.

http://forums11.itrc.hp.com/service/forums/questionanswer.do?threadId=1275654

I don't know what "tree command on UNIX" you're referring to, as there isn't one in the normal.

Also, from the previous post, would mounting the UNIX filesystem to Windows (or the other way around) resolve the issue?

[James R. Ferguson · Accepted solution]

Hi Deanna:

> I was think of using the tree command on UNIX

That's not ubiquitous. HP-UX doesn't have it, Linux distributions do. Of course, its easy to roll-your-own:

http://forums.itrc.hp.com/service/forums/questionanswer.do?threadId=1175074

Regards!

...JRF...

[Deanna Helie]

Steven Schwda and OLDschool;

I have heard from many people whoknow you that you like to insulted people when you either do not understand the question or do not know the answer. Very insecure and you need to grow up.

Before you insult any forums members, you need to look in the mirror first.

[Deanna Helie]

thanks James;

Good idea!

[OldSchool]

"Before you insult any forums members, you need to look in the mirror first...."

very well....

I merely pointed out that you said you solved it last year at this time, and asked one simple question...would mounting the filesystem locally via NFS or Samba would help address the issue.

I fail to see where that is insulting, but if you feel it is, it was NOT intended as such...

you might consider talking the advice you give as well

[OldSchool]

ok, I'm slow...but I finally understand what you're shooting for here (I think)

Assuming you're going to work with the various attachments that JRF pointed you at, I don't believe that I'd use the tree / ptree to have the server side of this "render" the tree, as I think that would make "drilling down" into the various subdirectories more difficult (you've have to track and insert the "new" contents in the existing tree and "re-render" it properly.

If you "render" the tree on the presentation / client side (in your newly created "save as"), then something like "find" might prove useful.

on opening the "save as" for the server / repository, it could or would start at the "/" directory (or whatever you tell it to start at)

find / -maxdepth 1 -type d

will return only a list of the directories that are under root. at that time you render the list into a tree on the client side. drilling down / selecting a "leaf" from the previously rendered list would then run

find -maxdepth -type d

which would return all of the directories under the leaf for insertion on the list, possibly followed by

find -maxdepth -type f

to list the existing files contained in that leaf


Note that in all case fo directories, the list contains the original / starting location as well as any directories immediately under them.

The downfall of this is that it puts the rendering on the client side, but in this case, I'd think it would be easier to deal with progamatically. You might also need to do some sorting, as I don't know that you can rely on find to return sorted results. And then there is always the issue of how you decide which "save as" to run (the windows api version or this one)...but if you're this far into it, I'd assume you've either already resolved that, or at least have a method in mind to address this.

An issue that arrises when generating the tree list on the server side, is that many of the tools noted recurse automatically down the directory from the starting point give. This could (potentially) be difficult to manage, and very time consuming. At least one of them listed
"ls -lr " which, of course, if executed from the root level list every file on the server.

The perl versions noted could be modified to limit the recursion if necessary

[Steven Schweda]

> find / -maxdepth 1 -type d

"-maxdepth" is a feature of GNU "find", not
of the HP-UX "find" program. A Forum search
for, say,
find maxdepth prune
might find examples which work with various
editions of "find".

Sorry, but I can't seem to think of a good,
"insulting" question to ask here.

[James R. Ferguson]

Hi (again) Deanna:

The '-maxdepth' option of 'find' isn't universally available, as noted.

If the rendering of a directory tree is the requirement, my preference remains 'readdir()' for a number of reasons. As I noted earlier, create a subroutine that calls 'readdir()' to read a directory. As subordinate directories are encountered, recursively call the subroutine, each time increasing the tree's indentation. You can track your own depth requirements and cease descent of sub-directories as you see fit.

The other value to a 'readdir()' approach, in my opinion, is that you can implement it in either C or Perl (the later which uses the C libraries).

Regards!

...JRF...

[OldSchool]

JRF: "If the rendering of a directory tree is the requirement, my preference remains 'readdir()' for a number of reasons...."

yep..the point I'm fumbling with trying to explain is that this is probably best done as some kind of "conversation" between the presentation / clientside and the server / data side. And since its done "one level" at a time, the rendering of the results is probably best done on the presentaion side...as opposed to having the data/server side both gather the info and render it.

I'd think you would want to select which item to drill into, as opposed to having the server side always recurse down from whatever starting object you tell it to look at.

In other words, give a starting leaf, you want the information on subdirectories and files immediately below it. You could / would then select one item off the list an drill into it if desired.

Deanna mentioned "graphical ftp" as an example of what she was looking to achieve...and those don't (at least the ones I've seen) crank out the complete tree at the initial connection. they step into one level at a time.

Having the client side actually render the tree seems, at least to me, allow that to happen in a more "natural" fashion, as you've got control of what to look at when, and when to look. The perl solution would certainly allow this to happen..but there was one (I think shell / awk based) the might not be so appropo, as it automatically recurses...

In rereading the above I'm not sure I've been very effective at describing how *I'd* envision this working....problem is I can "see" what I mean, but translating it into the written word is, well,...lacking.

[Deanna Helie]

I will check your ideas out and of course give points. I have been trying to complete this functionality for 4 years and always get pull off to do more important issues.

I am hoping to get this finished next year, since it is the end of 2009.

thanks to all and more to come......


FYI: They (upper management) want to give the UNIX users to same saveas finctionality as the windows base users. The frontend interface is the same the backend ( programs/files) are different.

[Deanna Helie]

I have not found the solution at this time.