Files not folded below folders in some cases

[0-wiz-0]

From the screenshot I assumed that I would get folders to fold up for the changed files. This happens for a few folders, but not many

The directory is there and a file is there, but there is no folding. (There is one for the main directory) In another case I have a filename "foo/bar/file.zip" but get just that, nothing for 'foo' or 'bar' and no folding. Perhaps I misunderstood what should happen here, please let me know.

[vfaronov]

The directory is there and a file is there, but there is no folding.

The directory and the file are distinct items in the sync plan. If the file were to be folded into the directory, then what should the Action column show for the directory, and what should happen if you change the action on it? If it only affects the directory, it would be inconsistent with the behavior for “virtual” directories (fiction in your example); and if it works recursively, there’d be no way to operate on the directory itself. This is why Gunison purposely doesn’t fold in such a case.

Maybe we can come up with a UI that would solve these problems. Ideas?

In another case I have a filename "foo/bar/file.zip" but get just that, nothing for 'foo' or 'bar' and no folding.

Gunison only folds multiple items. If you only have foo/bar/file.zip, then generating foo and bar folders would only add noise to the tree.

But this is easy to change. Would you like an option to toggle this behavior?

[vfaronov]

Now that I think about the first case, perhaps it isn’t much of a problem. Gunison already shows “•••” when a folder contains different actions, and this can be extended to the (likely uncommon) case where the directory itself has a different action, which would then be shown in the tooltip. And when you change the action, Gunison can just ask you whether to do it recursively. This would probably be overall more intuitive that the current behavior. This will take some work, though, so maybe not right now.

By the way, does your usual workflow imply directories often changing props (triggering this)?

[0-wiz-0]

Re: folding: I somehow expected the directories even if there was only one entry. Perhaps wait for more input from others.

Re: props: Yes, I use unison on a shared server and there's a nightly cronjob that fixes permissions so that other users can access/modify the files as well.

Thanks for the feedback!

[vfaronov]

This is now fixed in master, soon to be released as version 0.2.0.

The fix is as described above, except that action is always set recursively, without asking. If you wish to set action only on the directory item itself, you have to set it on the entire folder (recursively), and then reset it on all the children (select them all and click Revert in the context menu). I hope this slight inconvenience in an uncommon case will be outweighed by the simplicity and consistency.

The original behavior of squashing single-item folders (producing your foo/bar/file.zip) is now disabled by default, but if you upgrade from 0.1.0, you need to toggle it off manually in the context menu.

Even with this fix, some items may still not be folded: for example, when a conflicting foo/bar.txt is raised by Unison to the top of the list, Gunison may be unable to fold it with the rest of foo/. Full folding is only guaranteed if you sort the list by path ascending (click on the column), with squash disabled.

Thanks for raising this issue — this was fun to work on.

[0-wiz-0]

Thanks for working on this! I'm looking forward to the next release now :)

[vfaronov]

Released 0.2.0.