Symbolic Link, Hardlink and Junction creation is available via menu

[schinagl]

As mentioned this is the small part, which provides menu entries for symbolic/hardlink/junction creation

[tokomio-sun]

@clzls @craigwims

thank you for reviewing. I fixed full width '％' in Line 420.

Edit: and verbs are using different voices across these messages... Maybe 選択している or such is better?

I should fix.

FROM: 'ファイルを %s にリンクする'

TO: '%s にファイルをリンク中'

[schinagl]

@clzls @craigwims

thank you for reviewing. I fixed full width '％' in Line 420.

Edit: and verbs are using different voices across these messages... Maybe 選択している or such is better?

I should fix.

FROM: 'ファイルを %s にリンクする'

TO: '%s にファイルをリンク中'

If you think '%s にファイルをリンク中' is a better Japanese then, please change it. You can do it on your branch for #355, and we get it into master, once your branch is merged

[craigwims]

No, I don't have any insights into JAPANBEGIN and JAPANEND.

@schinagl, related to an earlier question about the difference between the control afforded by the menus and that of the drag/drop: I was not thinking of adding another menu item, but would like to consider restricting the drag/drop case to match the menu case. That is, use the logic on line 788 of wfdlgs2.c in the drag/drop code, which would simplify the cases.

[schinagl]

@craigwims please give a code snippet where you would like to place if (IsDirectory(pCopyInfo->pFrom)) otherwise we run in danger to talk about different things

As mentioned above the idea in general is: WFMoveCopyDriverThread() gets PCOPYINFO fully filled out from

• 'drag and drop' coding in wfcopy.c:3519
• 'menu coding' in wfdlgs2.c: 802

As of now WFMoveCopyDriverThread() is prepared to handle a fully filed out PCOPYINFO properly for the new FUNC_xxxx

The 'menu coding' of this PR now also needs to out fill PCOPYINFO properly in wfdlgs2.c:788

Anyhow please give a code snippet on what you would like to change in detail, so I can give a better answer.

[craigwims]

Line 316 of wfdirsrc.c: instead of setting iShowBitmap to DROP_HARD unconditionally, set to DROP_JUNC when the source of the drag/drop is a directory. The case in treectl.c, line 2903 always uses DROP_JUNC since the source there is always a directory.

[schinagl]

I guess I got your point

What I understood

Your concern starts in wfcopy.c:2776 and wfcopy:2810, because FUNC_HARD is used with oper == OPER_MKDIR In prosa:

• in this part a junction comes in and disguises as FUNC_HARD.
• it comes from wfdirsrc.c:316 because a dir is dragged in the file pane and thus is handled via FUNC_HARD

With the proposed change in wfdirsrc.c:316 to send FUNC_HARD or FUNC_JUNC according to the output of IsDirectory() the lines wfcopy.c:2776 and wfcopy:2810 could be deleted and thus would be more logical to an future developer.

Discussion

• We must not call IsDirectory() in wfdirsrc.c:316 because this code runs every time the mouse moves a pixel. Having a filesystem access here will destroy any performance.
• As far as I know we do not have any other inidcator of attributes here
• Furthermore one could have selected a file and a directory. See below

So we must do this in wfcopy:3495. But here things also will not work because

• directories come in properly and pFrom can be checked
• files come in here quoted and can be many. e.g. "\"bla - Copy - Hardlink.txt\" \"bla - Copy.txt\"". So one has to -- parse them into single items -- unquote them and check them

So

• unquoting and handling many is something which WFMoveCopyDriverThread() already does.
• should we do all in wfcopy:3495 beforehand? No, this is double effort.
• and whatbout having different types if you have many. e.g there is a file and a directory selected? Which FUNC_xxxx would you assign pCopyInfo->dwFunc?

Conclusio

Give it a try in the compiler yourself, you will see this would not work. Or create lots of unneccessary effort. We have to live with this disguise of junctions as FUNC_HARD in wfcopy.c:2776 when they are dragged from the file-pane. But we should comment it.

[craigwims]

Doing a file system operation on each mouse move is not a good idea; agreed.

Looking at this further, and reflecting on your comments, the difference between _HARD and JUNC seems very, very small. Why do we have both since at the bottom they both call WFJunction() which does not take FUNC* as a parameter?

[schinagl]

In most places we need a distinction

• wfcopy.c:1812 and wfcopy.c:2475 need it when we create -Copy/-Symlink/- Junctions/- Hardlink in the same directory. See #313
• Furthermore the hydraulics of printing out texts on dialogboxes also needs a differentiation. See lang\res_en-US.rc:303. This is a tricky index driven way of finding the proper strings (Was there ever since, but I extended it in the spirit of the author of this part)

In general I also wanted to separate this for readability and debug-ability. The only place where it didn't work out, was wfcopy.c:2776 where a Junction disguises as FUNC_HARD, when it comes from the file-pane

[schinagl]

Did my answers help? Is it good to go or do you need more time to try it out?

[craigwims]

A refinement of my idea above: use the logic at line 788 in wfdlgs2.c at line 3506 in wfcopy.c. In this case, we don't need DROP_HARD (always use DROP_JUNC), but we do need FUNC_HARD .vs. FUNC_JUNC.

This will also make the drag/drop from the right and left pane be the same; as noted above, there is a difference because the left pane contains only directories.

[schinagl]

Discussion

Please read my comment from above, I discussed this way already:

This does not work because (the most important of many reason)

• IsDirectory(pCopyInfo->pFrom) in wfdlgs2.c:788 always contains one item, because the input is from just the menu. That's why IsDirectory() works here.
• pCopyInfo->pFrom in wfcopy:3506 may contain many items in a quoted form ""MyFile.txt" "MyDirectory"" due to selection from the panes
• So you can't put pCopyInfo->pFrom into IsDirectory() in 3506 out of the box -- You have to parse pCopyInfo->pFrom into single items and unquote it. -- Assuming you have unparsed this here: On which of the many items are you going to use IsDirectory(), if you have e.g. a selection containing a file and a directory as outlined in my example above?
• Which FUNC_xxxx would you assign pCopyInfo->dwFunc?. PCOPYINFO may contain many files but one operation.

Please try this in the compiler yourself!

There are many other reasons from here and additionally:

• lang\res_en-US.rc:303. How would you create different error messages with a mixed type FUNC_HARDJUNC? wfcopy:3301 passes this on. Have a 'if IsDirectory()' here too? You would break the idea of how they selected texts.
• wfcopy:2344 You need to know if it is a directory like type by checking FUNC_JUNC. With a mixed type FUNC_HARDJUNC you don't know this

Summary

• If it is a 5 line change without any risk no problem, lets do it
• But it is not a small change to get rid of one single #define.

[schinagl]

But maybe there is a more radical way .... Trying out things ....

[schinagl]

The point of my above argument was IsDirectory() on many This would not work

But more radical .... If we

• completely get rid of DROP_JUNC
• almost get rid of FUNC_JUNC, except for wfcopy:3301, where make a hack for the error message

then things work. IsDirectory() on many is not needed, that's the key point

The drag and drop loop is now more symetrical between tree and file but many other places are not so obvious to understand.

Anyhow it works.