Discussion: sub-commands

[kofalt]

Discussion: sub-commands

[rfjakob]

Indeed it is a bit asymmetric. The reason is that I wanted to keep the most common action (mounting) as simple as possible and not require any argument.

EncFS handles the other actions in a seperate command ( http://linux.die.net/man/1/encfsctl ), but having two binaries instead of one seem undesireable as well.

[kofalt]

I'm not sure I understand the two binaries comment - to be clear I'm proposing all the commands stay within a single binary.

If you're interested, I could take a whack at a PR for this to try it out?

[rfjakob]

Do you have a plan for how to do that without complicating mount?

[rfjakob]

But to be honest, I'd rather see logging to syslog implemented. Or fallocate ( #1 ), which is a bit more technical, but I can provide guidance if needed!

[kofalt]

Fair enough! I think, if you were adamant about keeping the mount example the same, it could default to mounting if the parameter doesn't match any sub-commands.

I'll be honest, this is the first I've heard of fallocate so I don't think I'd be super confident taking that on. But I am open to becoming a general contributor once I've played with it a bit more. Gocryptfs looks like an ideal candidate for sharing encrypted files through conventional cloud providers with colleagues, though I've yet to see what the user-visible behaviour is in the case of conflicts (my guess is nothing good).

[rfjakob]

Regarding conflicts: Dropbox appends something like "conflicted copy 1" to the file name and keeps both versions if there is a conflict. This will work just fine with gocryptfs when file name encryption is disabled. Use the -plaintextnames flag to disable file name encryption.

[rfjakob]

I will close the ticket for as I don't think subcommands have enough merit to be implemented.

You are welcome to contribute on other open issues!

[spl]

I'm trying out gocryptfs for the first time, and, as a newcomer, the command-line flag documentation is a bit confusing. Also, I had to search the web for how to unmount, but that probably shouldn't be necessary.

One solution would be to improve the usage string. You could categorize and/or group related flags together. This should, for example, remove the need to add (with -init) at the end of some flags.

Another solution is to use subcommands as mentioned above. Personally, I find this approach better.

Subcommands are self-documenting to an extent because they present the primary actions as mutually exclusive alternatives and separate those from optional flags. Looking at the current set of flags, it requires some reading to realize that -init is a special case. I also have to think a bit about whether -init works with -ro, for example.

Subcommands also make it intuitive to get documentation on a subcommand and to determine which optional flags work with a subcommand. By typing (for example) gocryptfs <command> -h/--help, I can immediately learn more about <command>. And having this extra documentation not in the main usage string allows you to keep the latter brief.

To alleviate the concern about making the “mount” command easiest, you could use a subcommand “alias:” securefs uses m for mount.

Better usage documentation could, of course, improve things for newcomers like myself. But I think subcommands go an extra level by highlighting the discrete operations of gocryptfs in an intuitive way.

[sabrehagen]

I too came here searching for how to unmount a gocrypfs folder. It feels "wrong" to have to use a different program (fusermount) to reverse an operation taken the gocryptfs program.

[Nodens-]

This is the standard for all FUSE filesystems.