Couple of problems

[cxl]

Hi Leo, very nice work you are doing with this software. Keep up the good work!
As you will see I frequently use dopus flatview mode to organize my files

My problems are:
I am trying to create symbolic links to folders from a list in flat view mode. I tried to use the dopus command COPY MAKELINK=SYMBOLIC but the problems is that it creates sym links to folders not relative to the folder being linked (i.e C:\folder 1\folder 2\storage for symlinks\link to folder 2 is "c:\folder 1\folder 2" instead of "....\folder 2") In other words it creates absolute paths (full paths) just like junction links. Can you change this please? I really need to have relative paths.

In the mean time I tried to resolve this using a command line tool for symlinks and building a button for it with a dopus run script like this:
@runmode:hide
@async "C:\Windows\ln.exe" --symbolic {sourcepath$}{file} {destpath$}{file}
but there is a problem again as {sourcepath$} and other modifiers don't work in FLAT VIEW. Why? Are there any other way of taking tha path from a selected file (folder) in flatview mode?

The second bug (problem) is that in Flatview mode I can only filter files and not folders. While not in flatview mode everything is ok. I can searc for folders using filter or for file, but as I said I can't search for folders in flatview (using filters)

[kundal]

AFAIK the command Copy MAKELINK=SYMBOLIC doesn't exist in DOpus. The available Arguments for MAKELINK are hardlink, junction, softlink and auto. The Argument softlink should work for you.

Your code for ln.exe doesn't work with more than 1 File/Folder selected because you used {sourcepath$}{file}.
Use {filepath} instead and it should work.

[Leo]

{sourcepath} works fine with flat view; it gives you the path that the lister is currently in.

(It does not give you the path that any particular file is in; it has no way of knowing which file you mean. Use {filepath} for that, as Kundal suggests above.)

[cxl]

I am afraid you didn't understang well what I wrote. Look...
@runmode:hide
@async "C:\Windows\ln.exe" --symbolic {sourcepath$}{file} {destpath$}{file}
Works very well for any file/folder (kundal: multiple selections included) while not in flat view. It creates exactly the structure from the source file/folder selection to the right pane. Exactly. No problem.
But when I switch to flat view mode IT DOESN'T create anything, so I don't know what ARGUMENTS to use in FLATVIEW to create symlinks with that command script. I need an argument that would give in flat view the exact path and name for any folder and file selected. I would mostly need to create symlinks for folders. {filepath} i tried it doesn't pass to ln.exe the right path and name of folders/file (in
flatview).

Copy MAKELINK=SYMBOLIC, my mistake, I was thinking to symbolic links. Should have spelled correctly Copy MAKELINK=softlink
Again, Copy MAKELINK=softlink does not WORK as SUPPOSED. It creates symlink but THE PATH to WHERE it links IS NOT RELATIVE, but IT IS ABSOLUTE. The path to where it links is stored in the link, in absolute mode, exactly like when you use Copy MAKELINK=junction, when it should be relative.

I include here what the schinagl.priv.at/nt/ln/ln.html is writing about relative or absolute paths.
Absolute Symbolic Links
The target of a symbolic link can either be a fully qualified path starting at the root of a drive, e.g e:\data\cpp\myfile.txt or can be be specified relativeley, e.g ....\data\cpp\myfile.txt
ln.exe by default tries to create relative target path names for symbolic links as long as this is possible, e.g the file and its target are on the same logical drive.
Having relative symbolic link targets is much smarter especially when the target of links is in the same directory. If a symbolic link and its target are on different drives, ln.exe uses absolute pathnames.
If the creation of absolute target pathnames should be forced use the --absolute option.
ln --absolute --symbolic sourcefile.txt destination.txt
In the above example sourcefile.txt gets symbolycally linked to destination.txt, but the target path in the symbolic link is absolute.
ln --absolute --symbolic SourceDirectory DestinationDirectory
In the above example a symbolic link directory SourceDirectory gets symbolycally linked to DestinationDirectory, but the target path in the symbolic link is absolute.

And again, Flatview Mode Filter does not work well. If I put a folder in flatview mode and I try to search (with filter) for a folder that has some letters in it, it does not filter out the other that don't that don't have that letters in it.

[Leo]

[quote="cxl"]I am afraid you didn't understang well what I wrote. Look...
@runmode:hide
@async "C:\Windows\ln.exe" --symbolic {sourcepath$}{file} {destpath$}{file}
Works very well for any file/folder (kundal: multiple selections included) while not in flat view. It creates exactly the structure from the source file/folder selection to the right pane. Exactly. No problem.
But when I switch to flat view mode IT DOESN'T create anything, so I don't know what ARGUMENTS to use in FLATVIEW to create symlinks with that command script. I need an argument that would give in flat view the exact path and name for any folder and file selected. I would mostly need to create symlinks for folders. {filepath} i tried it doesn't pass to ln.exe the right path and name of folders/file (in
flatview). [/quote]

I think you haven't understood what we wrote.

To make it easier to see what's going on, run this command (set the Function drop-down to MS-DOS Batch Function):

Echo The sourcepath is: {sourcepath} Echo The destpath is: {destpath} Echo The file is: {file} Echo The filepath is: {filepath} Echo The file parent is: {filepath|..} Pause

Run that in your Flat View scenario and you'll see it works fine, and that {sourcepath} and {destpath} always -- even in Flat View -- give you the path that the source and destination file displays are in.

{sourcepath} and {destpath} do NOT give the path that the selected files are in. That is not what they are for! When you are not using Flat View or file collections, the source/dest folders happen to be the same as the folders where all the files are, but that is a coincidence and not how {sourcepath} and {destpath} are defined. If you want the full path to the selected file, use {filepath}. If you want the parent of that use {filepath|..}.

Again, Copy MAKELINK=softlink does not WORK as SUPPOSED. It creates symlink but THE PATH to WHERE it links IS NOT RELATIVE, but IT IS ABSOLUTE.

Where is it documented that Copy MAKELINK=softlink is supposed to create relative links? That is news to me.

The command always creates absolute links. If you want the ability to create relative ones, send a feature request via GPSoftware: Support Request and it might be added for a future version.

[steje]

I'm afraid that perhaps it is you that haven't understood what kundal and leo have written... maybe you didn't understand HOW to use what they suggested...?

The {sourcepath} code works in flatview just fine... The reason your ln.exe command is not creating anything is probably because you're passing it an invalid path based on how you're trying to use {sourcepath}. Try:

@async "C:\Windows\ln.exe" --symbolic {filepath} {destpath}{file}

When you're in flatview mode, the {sourcepath} code will only result in an accurate path to {file} if you're selecting ONLY files directly located in the folder you're actually in (in the location bar). If you have a nested folder structure like this:

D:\

• Folder 0
  -- Folder 1
  --- Folder 2
  ---- Folder 3 (contains a file called file.txt)

...and you're in "Folder 0" when you turn on flatview and select a file called file.txt that is located in "Folder 3"... then {sourcepath$}{file} will resolve to "D:[b]Folder 0[/b]\file.txt" and NOT to "D:\Folder 0\Folder 1\Folder 2\Folder 3\file.txt". So I assume you see the problem? In this case, how would you expect ln.exe to be able to make link to a file that doesn't exist in "Folder0"?

As for the rest... not sure why you're including info on ln.exe's description of relative and absolute paths . I think most folks here understand the difference without explanation. But as you've seen, Opus appears not to support relative path link creation. You'll want to submit an official feature request/program suggestion for relative link support using the official GPSoft website and support form (link in my signature). I might use that myself in folders where I create links to files in subfolders of the same parent folder... absolute paths mean those links will break if I have to move the entire parent folder to a different drive, or rename a parent folder...

[cxl]

Ok, sorry about not using {filepath} properly after you initial responses. I wouldn't have done that if I knew that I can use MSDOS batch script and pause after the commands.
I woud have understood on my own about what every file,path argument passes to the script.

Thus "C:\Windows\ln.exe" --symbolic {filepath} {destpath}{file} does what I want. The only problem left is that in flatview (all folders first, files after) if there are many folders/files with same name (different parent folders) I can't create links to all of them (instead ln.exe only creates links for the first) like Copy MAKELINK=softlink does by adding an index to the name ("(1),(2),...,(i)"). Can this be done with a vbscript or are there other arguments (msdos batch or dopus script) that I can use?

Copy MAKELINK=softlink, should create relative links as long as this is possible, e.g the file and its target are on the same logical drive. That is the logic for what symbolik links where introduced in the first place. So this should go to Support Issue -> Program Anomality not Program Suggestion, or am I wrong?

[/quote]Unlike an NTFS junction point (available since Windows 2000), a symbolic link can also point to a file or remote SMB network path. While NTFS junction points support only absolute paths on local drives, the NTFS symbolic links allow linking using relative paths. Additionally, the NTFS symbolic link implementation provides full support for cross-filesystem links. However, the functionality enabling cross-host symbolic links requires that the remote system also support them, which effectively limits their support to Windows Vista and later Windows operating systems.[quote]

http://en.wikipedia.org/wiki/NTFS_symbolic_link

Again, you seem to have overlooked the other problem I mentioned:
In FlatView Mode (folders and files alltogather, Mixed or Grouped) Filter does not filter out Folders, only Files. Is this a bug or not. Should I fill a bug report for this or I am getting this wrong?

(Don't get me wrong or misinterpret, but, I am not trying to sound aggressive to any of you in any of my posts. I am requesting your help, so how could I be)

[Leo]

@cxl

Copy MAKELINK=softlink, should create relative links as long as this is possible, e.g the file and its target are on the same logical drive. That is the logic for what symbolik links where introduced in the first place. So this should go to Support Issue -> Program Anomality not Program Suggestion, or am I wrong?

There's nothing about symbolic links that means they should inherently be made relative instead of absolute, and both types of symlink can be useful, so it's a feature request not a bug report.

(e.g. What if you want a symlink that always points to the same place even if you move it around?)

[quote]Again, you seem to have overlooked the other problem I mentioned:
In FlatView Mode (folders and files alltogather, Mixed or Grouped) Filter does not filter out Folders, only Files. Is this a bug or not. Should I fill a bug report for this or I am getting this wrong?[/quote]

Turn on Preferences / Miscellaneous / Advanced: flatview_folder_filters. (Also note that if a folder is filtered out, all files and folders below it will be filtered out as well. That confused so many people in the past that flat-view was made to only filter files by default, unless that setting was changed.)

BTW, this is part of the reason we ask that people post one question per thread (in general; of course, it the questions are closely related then it makes sense to ask them both in the same thread).

[cxl]

I switched the Advanced: flatview_folder_filters boolean. I also found that there is checkbox "Filter Folders in Flat View" that apears on the filter bar (using "*" key). I assume they refer to the same thing.
There is a problem tough, with many subfolders in flatview. If I flat out a folder that has about 20 subfolders the filter works fine for folders, but for a folder that has arround 200 it just doesn't work anymore. Probably a bug. I can't believe I am that unlucky. Everything that is important for me in using Dopus just doesn't seem to work.

[cxl]

Oh, I forgot to mention I am using the latest Dopus, 10.0.2.0.4269 x64

[Leo]

@cxl

I switched the Advanced: flatview_folder_filters boolean. I also found that there is checkbox "Filter Folders in Flat View" that apears on the filter bar (using "*" key). I assume they refer to the same thing.

Yes, they do the same thing. I forgot that checkbox was there when I was writing yesterday.

The Advanced/flatview_folder_filters setting affects other types of filters but isn't needed when using the Filter Bar (* key).

There is a problem tough, with many subfolders in flatview. If I flat out a folder that has about 20 subfolders the filter works fine for folders, but for a folder that has arround 200 it just doesn't work anymore.

What actually happens? "Just doesn't work anymore" tells us very little.

Can you give us some steps to reproduce what you are seeing?

I created 200 folders, some called See_NNN and some called Hide_NNN, each with a file below called VisibleFile.txt or FilteredOutFile.txt:

I then set the filter to show (See|Visible)* and it worked as it should:

So simply having 200 folders isn't enough to cause a problem, if there is a problem to be found here.

Note that I had to make my filter match both the folders and the files in order to see both. If the filter had only matched the files then nothing would be visible (since filtering out a folder also filters out everything below it). If the filter had only matched the folders then the folders would be visible, but not the files. And things get more complicated if the folders are nested (since when any folder is filtered out, the whole branch of folders below it is also filtered out.) That is often a source of confusion when filtering in flat-view.

Probably a bug. I can't believe I am that unlucky. Everything that is important for me in using Dopus just doesn't seem to work.

So far in this thread we've found zero bugs, and nothing in Opus that isn't working properly once you understand how it works. It's possible there is a bug in the flat-view folder filtering but it seems premature to assume that.

As I mentioned, one of the reasons folder filtering was disabled by default in flat-view is that so many people got confused by how it worked. This may just be another case of that.

Either way, if you can give us a concrete example showing folders that should be filtered in/out but aren't, and what your filter is set to, then we can try to either reproduce the bug you are seeing or explain why it isn't an bug, depending on what it is.

[cxl]

Sorry for the bother I may have caused. Indeed it was a misunderstanding of how FlatView Folder Filtering works, with nested folders (i used filtering on some windows folder, with just a few subfolders (but no nested ones, which I didn't know) and the filter worked, then on a few of my folders that contain many subfolders, and nested folders, and it didn't work, so I wrongly assumued it may be because of the large number of folders within).

I mainly use FLAT VIEW - MIXED (with folders) mode, where all the subfolders and files share the same level (in one big list). So I assume it would make sense to have the folder filter (when it's enabled) to filter all the nested folders and files, not just their parents, doesn't it?

The way it is now, from my point of view only makes sense for the other flat view mode - Grouped, but not for Mixed (with folders).