[Solved] File save issues on Synology NAS

Post here for help on using FreeCAD's graphical user interface (GUI).
Forum rules
and Helpful information
IMPORTANT: Please click here and read this first, before asking for help

Also, be nice to others! Read the FreeCAD code of conduct!
triplus
Posts: 8734
Joined: Mon Dec 12, 2011 4:45 pm

Re: File save issues on Synology NAS

Postby triplus » Sun Jan 27, 2019 6:38 pm

As already suggested test the FreeCAD 0.17 AppImage:

https://github.com/FreeCAD/FreeCAD/releases/tag/0.17

FreeCAD 0.17 AppImage still uses Qt4. It won't have the extension related issue. Maybe file saving will just start to work again.
sawozny
Posts: 20
Joined: Mon Aug 31, 2015 9:21 pm
Location: NYC

Re: File save issues on Synology NAS

Postby sawozny » Sun Jan 27, 2019 9:30 pm

Ah! Sorry, I thought your recommendation to run via the AppImage was only for the v18 test earlier. I just downloaded and ran the v17 AppImage and the file extension problem doesn't occur when I run FreeCAD that way. Just entered "Test Cube" in the save dialog and the extension was added automatically. I noticed that the AppImage version uses a different file dialog than the PPA version. I don't know how to identify them by name (if they have names), but they're definitely different. So does this mean this issue could just be a blip with this particular build in the PPA and next update things could go back to normal? I don't want to run via the AppImage permanently as that means I'll have to start watching for updates rather than have the Software Updater tell me when one is ready, but it's a great testing option and I'm glad you mentioned it. :)

Unfortunately, saving to the SMB share still results in a 0 byte file (at least this time with the extension, though). I think I'm going to run comparative strace tests and see if that helps identify a direction for troubleshooting.

Thanks,

Scott
triplus
Posts: 8734
Joined: Mon Dec 12, 2011 4:45 pm

Re: File save issues on Synology NAS

Postby triplus » Sun Jan 27, 2019 9:49 pm

I don't know why the native file dialog got enabled by default for FreeCAD 0.17 stable builds on PPA. If such build option won't get explicitly set, indeed for FreeCAD 0.18, once released, it won't be enabled by default anymore.

As for the save issue. OK therefore we can rule out the file dialog too. The problem is i don't have much more ideas anymore. As if it works with other software, that indicates there are no permission or underlying operating system issues involved. As you say FreeCAD could save files successfully from Ubuntu 16.04. That further indicates there is likely no general bug in FreeCAD.

There is a quirk somewhere. But it's not obvious to me, on where to look next. Synology has a log somewhere in its control panel. For "Windows/Samba/File sharing/transfer". Try to find that option and to enable it. Maybe the log will provide some further clues.
sawozny
Posts: 20
Joined: Mon Aug 31, 2015 9:21 pm
Location: NYC

Re: File save issues on Synology NAS

Postby sawozny » Mon Jan 28, 2019 5:38 pm

I enabled logging earlier in this process, but it didn't tell me anything was wrong, just what was happening.

In a save from LibreOffice, the file is created under a temp name, the data is written, and then the temp file is renamed to it's real name (with a delete of the previous file if it's a save-over). No further detail than that it happened (i.e. no OS result codes or anything like that).

In a 0 byte save from FreeCAD, the create happens for a file with the name requested with a long hex string as the extension, then a rename to the filename requested (no extension). No data write was logged after the create and before the rename which I think is probably failing somewhere inside the OS/GVFS/SMB subsystem and the NAS is simply following the instructions it got.

I think my next step is comparative straces. I'll report back if I manage to find the answer (or I give up and transfer to NFS) for the benefit of future generations. :)

Thanks for your help in this troubleshoot.

Scott
sawozny
Posts: 20
Joined: Mon Aug 31, 2015 9:21 pm
Location: NYC

Re: File save issues on Synology NAS

Postby sawozny » Mon Feb 04, 2019 12:28 am

No fix found yet, but I did determine it happens on other SMB shares. Looking to further isolate, I tried both SMB1 and SMB2 on my NAS and my Windows machine and in both cases, saves to SMB1 work fine, but saves to SMB2 fail in the 0 byte file manner described.
User avatar
kkremitzki
Posts: 1758
Joined: Thu Mar 03, 2016 9:52 pm
Location: Texas

Re: File save issues on Synology NAS

Postby kkremitzki » Mon Feb 04, 2019 12:51 am

Nice troubleshooting, it'll be interesting to see the results of this.
Like my FreeCAD work? I'd appreciate any level of support via Patreon, Liberapay, or PayPal! Read more about what I do at my blog.
User avatar
NormandC
Posts: 18534
Joined: Sat Feb 06, 2010 9:52 pm
Location: Québec, Canada

Re: File save issues on Synology NAS

Postby NormandC » Mon Feb 04, 2019 12:55 am

@kkremitzki

What about
triplus wrote:
Sun Jan 27, 2019 9:49 pm
I don't know why the native file dialog got enabled by default for FreeCAD 0.17 stable builds on PPA.
I pinged you in another topic about it last week. Since there is no switch available in 0.17 to go back to Qt's file dialog, this is quite a regression. The FCStd extension needs to be typed manually, otherwise the file is saved without it; and it can't be opened back by FreeCAD.
User avatar
kkremitzki
Posts: 1758
Joined: Thu Mar 03, 2016 9:52 pm
Location: Texas

Re: File save issues on Synology NAS

Postby kkremitzki » Mon Feb 04, 2019 12:57 am

NormandC wrote:
Mon Feb 04, 2019 12:55 am
I pinged you in another topic about it last week. Since there is no switch available in 0.17 to go back to Qt's file dialog, this is quite a regression. The FCStd extension needs to be typed manually, otherwise the file is saved without it; and it can't be opened back by FreeCAD.
Ah, I had seen the discussion on the issue but I must have missed a notification. Was there a decision about what needed to be done to fix the issue?
Like my FreeCAD work? I'd appreciate any level of support via Patreon, Liberapay, or PayPal! Read more about what I do at my blog.
User avatar
NormandC
Posts: 18534
Joined: Sat Feb 06, 2010 9:52 pm
Location: Québec, Canada

Re: File save issues on Synology NAS

Postby NormandC » Mon Feb 04, 2019 1:05 am

There is no other choice on this but to revert to Qt's dialog. The native dialog on GNOME desktops doesn't add the file extension. There is a switch for it in the CMake build process, FREECAD_USE_QT_FILEDIALOG. Apparently you turned it off in the last package update (freecad_0.17.13541-1ppa10).
sawozny
Posts: 20
Joined: Mon Aug 31, 2015 9:21 pm
Location: NYC

Re: File save issues on Synology NAS

Postby sawozny » Tue Feb 05, 2019 12:15 am

For anyone following along, my earlier statement about this working fine under Ubuntu 16 and not under Ubuntu 18 turned out to be only because Ubuntu 16.04 only speaks SMB1 out of the box and my share was set to allow SMB1 connections if SMB2 didn't work out. So the issue is really SMB1 vs SMB2 and not Ubuntu version related because when I made the Ubuntu 16 system connect to the share over SMB2 the 0 byte problem happened. So while I was hoping to do comparative straces between working Ubuntu 16.04 talking to an SMB2 share and non-working Ubuntu 18.04 talking to an SMB2 share, SMB2 connections from both have this 0 byte file problem.

So, I proceeded to compare the straces between SMB1 and SMB2 saves on the same Ubuntu 18.04 system. What I found was in an SMB1 save, at the moment of truth, this system call happens:

Code: Select all

openat(AT_FDCWD, "/run/user/1000/gvfs/smb-share:server=diskstation,share=fileshare/Test Cube.042708c2-dad1-487c-ab5f-3187f9fa4e4c", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 34
The 34 is the file handle and the system proceeds to write to that file handle, like:

Code: Select all

write(34, "PK\3\4\24\0\0\0\10\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\f\0\0\0Do"..., 1004) = 1004
and so on until the whole file is written, then it does the rename and checks it's work by making sure there is no file with that destination name, doing the actual rename and then making sure there is a file with the name expected in that location:

Code: Select all

access("/run/user/1000/gvfs/smb-share:server=diskstation,share=fileshare/Test Cube", F_OK) = -1 ENOENT (No such file or directory)
rename("/run/user/1000/gvfs/smb-share:server=diskstation,share=fileshare/Test Cube.042708c2-dad1-487c-ab5f-3187f9fa4e4c", "/run/user/1000/gvfs/smb-share:server=diskstation,share=fileshare/Test Cube") = 0
access("/run/user/1000/gvfs/smb-share:server=diskstation,share=fileshare/Test Cube", R_OK) = 0
And all is well in the world. I have a working file on my SMB1 share.

In the SMB2 scenario, the original file creation has some sort of problem:

Code: Select all

openat(AT_FDCWD, "/run/user/1000/gvfs/smb-share:server=diskstation,share=fileshare/Test Cube SMB2.435bf00e-f823-40d2-b216-c98834210f3f", O_WRONLY|O_CREAT|O_TRUNC, 0666) = -1 EINVAL (Invalid argument)
This return is despite the fact that there IS, indeed, a file of that name in that location, which we will see below. So, in the absence of a file handle, no writes occur but the code proceeds to the rename stage as if it had written the file (which is probably why no screen feedback occurs that there was an error). The rename happens via the standard process of checking to see if the destination name is in use, doing the rename and then checking for the file of the new name, but since there was no data written to the file (how could there be with no file handle returned in the first place?) the file is 0 bytes:

Code: Select all

access("/run/user/1000/gvfs/smb-share:server=diskstation,share=fileshare/Test Cube SMB2", F_OK) = -1 ENOENT (No such file or directory)
rename("/run/user/1000/gvfs/smb-share:server=diskstation,share=fileshare/Test Cube SMB2.435bf00e-f823-40d2-b216-c98834210f3f", "/run/user/1000/gvfs/smb-share:server=diskstation,share=fileshare/Test Cube SMB2") = 0
access("/run/user/1000/gvfs/smb-share:server=diskstation,share=fileshare/Test Cube SMB2", R_OK) = 0
My next step is to see if there's a way for me to dig further into the openat call and see what went wrong on the SMB2 connection vs the SMB1 connection getting a file handle returned.

Does anyone familiar with the code know where I could locate the interactive file save code? Maybe looking at the calls in a higher level language might provide some insight I'm not getting from the system calls.

Thanks,

Scott