Empty directory's size for a mounted 'crypt' remote

Background: as I was working on creating an encrypted backup ("type = local" + "type = crypt") of sensitive data, I wanted to make sure my backup is binary the same as the source. When comparing mounted backup with original directory via external tool (Beyond Compare) I got unexpected 'Not a typewriter' error for one of subdirs. I do not ask for support with the tool, just wanted to share my observations.

The issue seems to be caused by comparison of 2 empty directories - one from ext4 file system, the other one from 'fuse.clone'. Typically, for Linux OSes the size of empty directory is is reported to be the same as 'block size' for vfs:

user@host:~/Desktop/$ ls -lh
total 4,0K
drwxr-xr-x 2 user user 4,0K dec 16 00:54 empty

where for encrypted remote it is '0':

user@host:~/mount/enc/$ ls -lh
total 0
drwxr-xr-x 1 user user 0 dec 16 01:35 empty

Also, "ls -a" does not return '.' or '..':

user@host:~/mount/enc/$ ls -a

Do you think it may be something worth pursuing (for compatibility reasons), or is it rather unrewarding corner case?

Best Regards,

EDIT: Verified with rclone v1.45

I wonder if it's more related to what the remote is reporting back as you are mounting a cloud remote and many of those concepts don't translate back.

What remote are you using?

It is not a cloud remote, but a local one. Relevant part of rclone.conf:

type = local

[local enc]
type = crypt
remote = local:/x/y/z/
filename_encryption = standard
directory_name_encryption = true

that is years old, you should update and test again

Debian stable :slight_smile:

TBH - I did not expect something like this to change and with v1.53.3 I can see the same behavior.

Oh sorry, I did see that as well and read past it.

Perhaps @ncw can chime in and explain why "." and ".." don't show up as I can see on another fuse mount (mergerfs), I do see them.

ENOTTY is "Not a typewriter". That means that the tool tried to do an operation for a TTY on a non TTY.

Empty, huh!

I doubt that will make a difference (but I could be wrong!)

This is more likely to cause a problem. It is the FUSE file systems job to add "." and ".." I forgot!

Try this which adds "." and ".." to directories. This matches rclone cmount which is used on Windows and macOS so seems like a sensible choice.

v1.54.0-beta.4970.86f1a5e01.fix-mount-dot-dotdot on branch fix-mount-dot-dotdot (uploaded in 15-30 mins)

1 Like

That is working fine for me:

felix@gemini:~/test$ ls -al
total 2178
drwxrwxr-x  1 felix felix       0 Dec 16 07:22 .
drwxr-xr-x 21 felix felix    4096 Dec 16 07:22 ..
-rw-rw-r--  1 felix felix     413 Oct 12 13:16 blah

with just a simple mount

felix@gemini:~/rclone-v1.54.0-beta.4970.86f1a5e01.fix-mount-dot-dotdot-linux-amd64$ ./rclone mount GD: /home/felix/test -vv
2020/12/16 07:22:40 DEBUG : rclone: Version "v1.54.0-beta.4970.86f1a5e01.fix-mount-dot-dotdot" starting with parameters ["./rclone" "mount" "GD:" "/home/felix/test" "-vv"]
2020/12/16 07:22:40 DEBUG : Creating backend with remote "GD:"
2020/12/16 07:22:40 DEBUG : Using config file from "/opt/rclone/rclone.conf"
2020/12/16 07:22:41 DEBUG : Google drive root '': Mounting on "/home/felix/test"
2020/12/16 07:22:41 DEBUG : : Root:
2020/12/16 07:22:41 DEBUG : : >Root: node=/, err=<nil>
2020/12/16 07:22:47 DEBUG : /: Attr:
2020/12/16 07:22:47 DEBUG : /: >Attr: attr=valid=1s ino=0 size=0 mode=drwxrwxr-x, err=<nil>
2020/12/16 07:22:48 DEBUG : /: ReadDirAll:
2020/12/16 07:22:48 DEBUG : /: >ReadDirAll: item=9, err=<nil>
2020/12/16 07:22:48 DEBUG : /: Lookup: name="blah"
2020/12/16 07:22:48 DEBUG : /: >Lookup: node=blah, err=<nil>
2020/12/16 07:22:48 DEBUG : blah: Attr:

The same result as for @Animosity022 - with this fix it works just fine.

Thank you!


I've merged this to master now which means it will be in the latest beta in 15-30 mins and released in v1.54

Once again - thanks a lot. I do appreciate your hard work!

1 Like

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.