All files show size of 0 with Synology DS415+ DSM 5.2-5592 Update 4

[vertigo235]

OK lets try this again...

I seem to have figured out how to fix my issue, but it really doesn't make any sense to me.

I have a Synology DS415+ which is an Intel INTEL Atom C2538, it reports as Linux, x86_64 to fuse.py, so it assigns c_stat class setup as follows.

        c_stat._fields_ = [
            ('st_dev', c_dev_t),
            ('st_ino', c_ulong),
            ('st_nlink', c_ulong),
            ('st_mode', c_mode_t),
            ('st_uid', c_uid_t),
            ('st_gid', c_gid_t),
            ('__pad0', c_int),
            ('st_rdev', c_dev_t),
            ('st_size', c_off_t),
            ('st_blksize', c_long),
            ('st_blocks', c_long),
            ('st_atimespec', c_timespec),
            ('st_mtimespec', c_timespec),
            ('st_ctimespec', c_timespec)]

I forced it to use the i686 setup

        c_stat._fields_ = [
            ('st_dev', c_dev_t),
            ('__pad1', c_ushort),
            ('__st_ino', c_ulong),
            ('st_mode', c_mode_t),
            ('st_nlink', c_uint),
            ('st_uid', c_uid_t),
            ('st_gid', c_gid_t),
            ('st_rdev', c_dev_t),
            ('__pad2', c_ushort),
            ('st_size', c_off_t),
            ('st_blksize', c_long),
            ('st_blocks', c_longlong),
            ('st_atimespec', c_timespec),
            ('st_mtimespec', c_timespec),
            ('st_ctimespec', c_timespec),
            ('st_ino', c_ulonglong)]

And this seems to solve my problem, while this seems like a fuse.py issue, that developer hasn't made any commits since 2013, so I'm not sure the proper way to fix this.

Anyhow, it seems to fix my issue, I can manually make this change with any future commits you make, but this is here for anyone else that might wish to use this awesome fuse mount for Amazon Cloud Drive.

[vertigo235]

Is it possible that my libfuse library is 32 bit even though I have 64 bit machine and that is why this is happening? The libfuse library was just in the /lib folder so I'm not sure what version it is. Perhaps it is packaged with Synology OS. Thoughts?

[yadayada]

The OS image I downloaded at https://www.synology.com/en-global/support/download/DS415+ contains a 32bit libfuse.

$ file libfuse.so.2.9.3
libfuse.so.2.9.3: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, stripped

What do you get when executing

uname -a; python3 -c 'import platform; print(platform.machine())'

?

[vertigo235]

Linux ds415plus 3.10.35 #5592 SMP Wed Aug 19 13:38:18 CST 2015 x86_64 GNU/Linux synology_avoton_415+
x86_64

If you downloaded the image and it had 32bit libfuse that is probably what it is. Odd that they would do that. How can I verify that my libfuse library is 32bit?

[yadayada]

Everything in that DSM image seems to be 32bit.

How can I verify that my libfuse library is 32bit?

Didn't we have this exact conversation two days ago?

Let's recapitulate: ctype.util.find_library didn't find libfuse. You then overrid the libfuse path manually. Please give a convincing reason why, in this case, fusepy (or I) should check if libfuse was built for a different architecture.

Addendum: I'm merely asking you to convince me, because I don't think this is a common problem. It's hardly condescending if I tell you that you should try (and are able) to find out something for yourself.

[vertigo235]

Thanks for your help, I know how to make it work on my system now, even if I have to edit the fuse.py file each time you make an update, and it works great. It doesn't look like the "file" command is packaged with Synology so I wasn't able to confirm it is 32bit, but I'm sure it is since everything adds up. My primary machine is a Windows PC and I don't have time to create a virtual environment etc to just run the file command on the library to confirm though.

I guess the only reason you would want to check is so that no other future users experience the same problem I experienced. I suspect more people will try to use the acd_cli utility and they also may have a 32 bit libfuse library with their 64 bit device.

Anyhow, thanks again for helping me out, despite your condescending attitude. Not everyone is as smart as you or has the same level of experience with Python, Linux, or general programming. I suspect you don't spend much time working with end users and there is certainly nothing wrong with that, because generally that is a complete nightmare.

Consider this issue closed.

[soakes]

I must admit, ive found the same issue if I run within a chroot on a Sybology NAS as what @vertigo235 has found.

The sizes and content are all zero sized which is why I then tried to do it on the core box and not within the chroot due to I originaly believed the issue with to do with the chroot.

FYI, I am running a DIY made Synolgy NAS on a HP Microserver Gen8 but in essence its exactly the same as a native one, it even uses the original playload just with a different/modifed boot media.

This issue which @vertigo235 says regarding the zero size and zero content, I found to be present within a 64bit Debian Jessie chroot running on the Synology NAS. This issue was not present on an RPI B+ running arm7.

I also have tried fuse mounting on real virtual machines running Debian 64bit and it works as expected (perfect). I sadly didnt get chance to test it on a 32Bit version as I don't have any machines handy.

I sadly failed to get it to load correctly on the core of the Synology NAS no matter what I did (libfuse is missing and requires a rebuild, then it should be ok, I think).

What the problem seems to be that the kernel is 64Bit but the libs/system are 32Bit hence the caculations are not working correctly due to using the wrong function. This issue I believe is because the debian-chroot package in synolgy repo seems to be 32bit hence causing the problem.

I have had to do the same fix, i.e. adjust the fuse.py file as to what @vertigo235 said and it now works perfectly, so big thank you to you for finding that as I dont think I would of found any time soon.

I know its not the right way to fix it and this is just a bandaid but every other ways I have tried to get this to work correctly on Synolog has failed. I am however more then willing to try any adjustments so that people don't have to hack core system files which likley will be overwritten. I never have like or one to use temp hacks but in this case I have no choise.

Heres my info taken within the debian chroot and as you can see its a 64bit kernel with 32bit libs.

$ file -L /lib/i386-linux-gnu/libfuse.so.2
/lib/i386-linux-gnu/libfuse.so.2: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, BuildID[sha1]=89bfe6e2224bafac779dcd68ea08b42fbe0718b1, stripped

$ uname -a; python3 -c 'import platform; print(platform.machine())'
Linux DiskStation 3.2.40 #4 SMP Wed Aug 20 13:04:11 CST 2014 x86_64 GNU/Linux
x86_64

I hope this info helps, if not, very sorry for the noise.