Does this function already exist ?

[Ysl]

Hi

I use a shell extension called FileFrog, http://www.filerfrog.com/15.html and I use a lot this function :

Extra tip from the frog: Move Up option from Organize will move the selected files and folders to the folder above the current folder. Just select files and/or folders and select Move Up and your selection will bounce to the folder above.

I would like to use it from XY but I do not see it in XY but maybe is it "hidden" somewhere ?

[admin]

Funny because when I added configurable custom shell menu items some days ago, I thought about adding "Move Up" as a further option. Well, I guess I'll do it now.

[Jibz]

It's not as easy as it appears, at least if you want it to work in general.

But if you limit it to what Explorer can do, it's easy.

[admin]

It's not as easy as it appears, at least if you want it to work in general.

But if you limit it to what Explorer can do, it's easy.

What do you mean?

[Jibz]

What do you mean?

Well, imagine one of the items you are moving is a folder with the same name as the parent folder. Then the order in which you traverse the tree suddenly matters.

http://www.hardtoc.com/archives/198

The algorithm there still has a kink; it doesn't always remove such recursive paths after moving.

Since everybody seems to be ignoring this issue, including Windows Explorer, you can probably get away with doing so too .

[admin]

What do you mean?

Well, imagine one of the items you are moving is a folder with the same name as the parent folder. Then the order in which you traverse the tree suddenly matters.

http://www.hardtoc.com/archives/198

The algorithm there still has a kink; it doesn't always remove such recursive paths after moving.

Since everybody seems to be ignoring this issue, including Windows Explorer, you can probably get away with doing so too .

Wow, good stuff! I will add a correctly working procedure in 9.70 (so that you can add a little footnote to your article ).

[admin]

I just added the primitive version to the current beta -- could not resist. I was shamelessly encouraged by the fact that "the others" don't do it any better.

Later, after the release of 9.60, I will improve the algorithm to handle "recursive collision" or what you want to call it.

[Ysl]

Thanks for implementing this function, and so fast !

Ysl

[admin]

I just added the primitive version to the current beta -- could not resist. I was shamelessly encouraged by the fact that "the others" don't do it any better.

Later, after the release of 9.60, I will improve the algorithm to handle "recursive collision" or what you want to call it.

Well, I made it a bit cheaper: I added at least a warning (in v9.60.0002).

[Jibz]

Well, I made it a bit cheaper: I added at least a warning (in v9.60.0002).

I think that is a very good solution .

One thing though, if the destination is further up the path, it would be better to check if the entire path from destination to source is present in source instead of just the first folder. For example, if I have

\parent\foo\bar\baz\zoo\zeb\foo

and I am in \parent\foo\bar\baz\zoo\zeb and try to move foo out to \parent I get a warning even though there is no chance of an overlap.

Or in general, if Special is the relative path from Destination to Source (i.e. Source == Destination\Special), then if Source\Special exists there is a possibility of an overlap.

[admin]

Well, I made it a bit cheaper: I added at least a warning (in v9.60.0002).

I think that is a very good solution .

One thing though, if the destination is further up the path, it would be better to check if the entire path from destination to source is present in source instead of just the first folder. For example, if I have

\parent\foo\bar\baz\zoo\zeb\foo

and I am in \parent\foo\bar\baz\zoo\zeb and try to move foo out to \parent I get a warning even though there is no chance of an overlap.

Or in general, if Special is the relative path from Destination to Source (i.e. Source == Destination\Special), then if Source\Special exists there is a possibility of an overlap.

Ah yes, right.

[admin]

Well, I made it a bit cheaper: I added at least a warning (in v9.60.0002).

I think that is a very good solution .

One thing though, if the destination is further up the path, it would be better to check if the entire path from destination to source is present in source instead of just the first folder. For example, if I have

\parent\foo\bar\baz\zoo\zeb\foo

and I am in \parent\foo\bar\baz\zoo\zeb and try to move foo out to \parent I get a warning even though there is no chance of an overlap.

Or in general, if Special is the relative path from Destination to Source (i.e. Source == Destination\Special), then if Source\Special exists there is a possibility of an overlap.

I made a new experiment with Explorer (identical results with XY). In your first test case (repeated here below), I go into \parent\foo\foo (sic!), and move all contents upward to \parent\foo, and the result is a desaster. Of 6 TXT files, 4 are gone (2 "first" correctly overwritten, but 2 "second" simply lost). Can you confirm this?

Code: Select all

\---parent
    \---foo
        |   a.txt ; "first"
        |   z.txt ; "first"
        |
        \---foo
            |   a.txt ; "second"
            |   z.txt ; "second"
            |
            \---foo
                    a.txt ; "third"
                    z.txt ; "third"

I would not have expected this, and now I'm unsure how to test for this case. But maybe, hopefully, I made a mistake somewhere...

[Jibz]

I made a new experiment with Explorer (identical results with XY). In your first test case (repeated here below), I go into \parent\foo\foo (sic!), and move all contents upward to \parent\foo, and the result is a desaster. Of 6 TXT files, 4 are gone (2 "first" correctly overwritten, but 2 "second" simply lost). Can you confirm this?

I get the same here. When you move from \parent\foo\foo to \parent\foo, you will get the set of "first" files overwritten, but the set of "second" files disappear because of the overlap issue.

If I try to do the move from \parent\foo to \parent here, Explorer stops with an error in the middle of the move.

I would not have expected this, and now I'm unsure how to test for this case. But maybe, hopefully, I made a mistake somewhere...

I think the test is the same .. the path from destination to source (here foo) is present under source as well, so there is a possible overlap.

[admin]

I made a new experiment with Explorer (identical results with XY). In your first test case (repeated here below), I go into \parent\foo\foo (sic!), and move all contents upward to \parent\foo, and the result is a desaster. Of 6 TXT files, 4 are gone (2 "first" correctly overwritten, but 2 "second" simply lost). Can you confirm this?

I get the same here. When you move from \parent\foo\foo to \parent\foo, you will get the set of "first" files overwritten, but the set of "second" files disappear because of the overlap issue.

If I try to do the move from \parent\foo to \parent here, Explorer stops with an error in the middle of the move.

I would not have expected this, and now I'm unsure how to test for this case. But maybe, hopefully, I made a mistake somewhere...

I think the test is the same .. the path from destination to source (here foo) is present under source as well, so there is a possible overlap.

OK, I think I got it now. I got shortly lost in the thickage of bar\baz\zoo\zeb\foo...

[Jibz]

OK, I think I got it now. I got shortly lost in the thickage of bar\baz\zoo\zeb\foo...

Hehe yeah .. I did get myself into a bit of a mess with those names .