Suppose you have a path (say, reported by a utility that looks for differences between two different folders).
Having got a path, you want to go there.
The find box does not work properly on an entry that contains the \.
The address bar also does not accept such partial path.
What is the proper way to go to the file?
How to find a path
Moderators: fgagnon, nikos, Site Mods
The "." is the grammatical end of my sentence (there is no period in the path I am handling).
The path is in aaa\bbb\ccc format.
Somehow the top-end of the path is not given. The file name ("ch01.html") is so common that I am sure to get a lot of files in the find result.
So I wanted some trick through which I can find this path.
I tried padding the path with *, but it does not work.
The path is in aaa\bbb\ccc format.
Somehow the top-end of the path is not given. The file name ("ch01.html") is so common that I am sure to get a lot of files in the find result.
So I wanted some trick through which I can find this path.
I tried padding the path with *, but it does not work.
this is an interesting scenario, although i can't imagine an app that would give out partial results like that. What about searching for clues in this app first -- e.g. its current directory
the address bar would understand complicated relative paths but only if they related to the current folder, so it wouldn't be much help. Find files wouldn't want to know either
if your "ccc" part is common as grass then perhaps you could search for the parent "bbb" bit instead, or "aaa", whatever is expected to give less hits
which is this program you're using anyway?
the address bar would understand complicated relative paths but only if they related to the current folder, so it wouldn't be much help. Find files wouldn't want to know either
if your "ccc" part is common as grass then perhaps you could search for the parent "bbb" bit instead, or "aaa", whatever is expected to give less hits
which is this program you're using anyway?
Yes, I had also thought of this, but first wanted to see if there is some trick to lessen the work (y'know, like the puzzle: "There are 10 balls, one weighs slighly more. Find which one, by weighing just once." ?)
I am always on the lookout for such productivity-boosting tricks. (In layman's terms, pure laziness..)
>>which is this program you're using anyway?
Why look a gift horse in the mouth? It's a freeware!
I am always on the lookout for such productivity-boosting tricks. (In layman's terms, pure laziness..)
>>which is this program you're using anyway?
Why look a gift horse in the mouth? It's a freeware!
That was a dummy puzzle! 
OK, the real problem is limitations in the folder comparator:
1. It describes the differences in terms of relative path from the current folders on both sides. (There are two "current" folders: one for each "side" being compared).
2. It does not have address bar: users have to select two folders by browsing a built-in folder tree. This tree does not allow right-clicking to check the item's "properties" box.
So, to derive the absolute path of any item reported as "different/missing", you have to add its relative path to the absolute path of the current folder, manually.
To avoid this unnecessary labour, I wanted to use only the relative path and zero on the item.
OK, the real problem is limitations in the folder comparator:
1. It describes the differences in terms of relative path from the current folders on both sides. (There are two "current" folders: one for each "side" being compared).
2. It does not have address bar: users have to select two folders by browsing a built-in folder tree. This tree does not allow right-clicking to check the item's "properties" box.
So, to derive the absolute path of any item reported as "different/missing", you have to add its relative path to the absolute path of the current folder, manually.
To avoid this unnecessary labour, I wanted to use only the relative path and zero on the item.