Network client-server setup

[fireant]

Hello,

I would like to offer my solution to searching network drive and ask a question.

Let me first explain my solution (so others can benefit as well). For simplicitys sake i dumbed it down a bit, original setup is done with DFS.
Lets say you have two computers:
- Computer1 has two drives (C:, D:), and has a share (\\computer1\share1 that targets C:\Share1)
- Computer2 is a client that wants to search network share of mapped drive T: (\\computer1\share1)

I have set up Computer1 like this:
Mapped virtual drive, so the name of the drive is the same as on client(s):
subst.exe t: c:\Share1
In everything i have installed it as a service, included newly created virtual drive T: in database and turned on ETP server

On Computer2 i run Everything and connect to ETP server and specify "Link type" as C:

So far so good, everything works perfectly and clients rely on central server instead of indexing everything by themselves everyday. That is optimal solution i hope (if not, point out what can be improved).

So now the question:
I have a folder on D:\Share2 that i want to include in search, and it is in share of T:\Share2. If i do a folder junction (mklink /j t:\Share2 d:\Share2 it does not appear in search results. How can i nest the folder so clients get result as T:\Share2 as they do for everything else that is on T:\ (c:\Share1 on server).

Thank you.

[void]

ETP is the most efficient.
Folder indexing in 1.4.1 has greatly improved.

Please try setting up a new ETP rewrite pattern:

• On the Everything ETP client PC:
• Completely exit Everything (Right click the Everything system tray icon and click Exit)
• Open your %APPDATA%\Everything\Everything.ini
• Change the following lines:
  etp_client_rewrite_patterns=
  etp_client_rewrite_substitutions=
  to:
  etp_client_rewrite_patterns=D:\Share2
  etp_client_rewrite_substitutions=T:\Share2
• Save changes and restart Everything.

Basically what you put in patterns is replaced with the substitution string.
etp_client_rewrite_patterns is a pattern list, use , to separate values. (eg, etp_client_rewrite_patterns=D:\Share2,D:\Share3,D:\Share4,...)
There must be a substitution for each pattern (eg, etp_client_rewrite_substitutions=T:\Share2,T:\Share3,T:\Share4,...)
The pattern must match what is on your server (they ignore your link type). D:\Share2 in your case.

http://www.voidtools.com/support/everyt ... e_patterns
http://www.voidtools.com/support/everyt ... stitutions

[fireant]

Thank you. Your solution is indeed very good.
Would it be possible if one could do a rewrite on the server side, so clients do not need to be updated like this?

[mattrix007]

I agree, that it would be a lot better to have etp_server_rewrite_*

That said, i am unable to make it work.

On my server, I have drive E: and it's shared out as \\server\dfs\engineer ... to make things work, i made sure the E$ share worked and tell the users to use \\server\c$ style links. And that works.

But i have always wanted links that look like the way things are actually shared, through the dfs.

I set up the etp_client_rewrites and no matter which of the link styles i choose in while making the connection to the ETP server, i get the same location tree in the Everything window on the client side, which matches the link style.

I have tried a lot of combinations, in quotes, not in quotes, when it quotes with double \ etc etc.

Also, have tried to use patterns that look like the \\server\c$ links:
etp_client_rewrite_patterns="\\\\server\\E$"
etp_client_rewrite_substitutions="\\\\server\\dfs\\engineer"

It never worked. But what i just noticed is when i look back in the INI file, the rewrites entries are gone.

Version is Version 1.4.1.895 (x64)

Thanks.

[void]

On your ETP client, please change:
etp_client_rewrite_patterns="\\\\server\\E$"
etp_client_rewrite_substitutions="\\\\server\\dfs\\engineer"

to:

etp_client_rewrite_patterns="E:\\dfs"
etp_client_rewrite_substitutions="\\\\server\\dfs"

Note: etp_client_rewrite_patterns must match the path on the server.

[mattrix007]

Thank you for the reply; does it matter which link style is chosen when the ETP client connection is being initiated if the client rewrite is being used?

I'm still striking out.

Let's pick a concrete. I have a K:\ on the server. It is shared as \\server\k$ and as \\server\box$ and as \\server\dfs\box. Note that the dfs layer is a Microsoft DFS which i'm using as a traffic cop to obfuscate the shares, etc. The dfs folder doesn't exist in the drives/shares.

On my PC, in the ini file, i put

etp_client_rewrite_patterns="K:\\"
etp_client_rewrite_substitutions="\\\\server\\dfs\\box\\"

and that doesn't work. Also, when i exit the client, the etp_client_* lines are blank. I connect using c: style links and \\server\c$ style but no difference.

etp_client_rewrite_patterns="K:\\"
etp_client_rewrite_substitutions="\\\\server\\box$\\"

doesn't work. Also, when i exit the client, the etp_client_* lines are blank. I connect using c: style links and \\server\c$ style but no difference.

Appreciate your help and your software.

[void]

Thank you for the reply; does it matter which link style is chosen when the ETP client connection is being initiated if the client rewrite is being used?

No, the ETP client receives the full path and filename as it would appear on the server, eg, K:\folder\file.txt
Rewrites are applied first, and then the link is converted to your desired link type.

Please try:
etp_client_rewrite_patterns="K:"
etp_client_rewrite_substitutions="\\\\server\\dfs\\box"

and that doesn't work. Also, when i exit the client, the etp_client_* lines are blank. I connect using c: style links and \\server\c$ style but no difference.

Please make sure you exit Everything before changing your Everything.ini (otherwise settings will be lost when you exit Everything)

[mattrix007]

Success!!!

Doesn't like the trailing slashes for me in the patterns or substitutions.

I have this many working:
etp_client_rewrite_patterns="E:","F:","G:","H:","I:","J:","K:","L:","N:","P:","R:","S:","V:","W:","X:","Y:"

And they're not vanishing any more!