Exporting and then opening a .grist file doesn't work correctly

[ruudschouten]

Currently on version 0.2.1, and wanted to export a newly created document.

Exporting is done by opening the document, clicking Share > Download.

If I then try to import this exported .grist file, I get a warning popup which says:

Import failed: File format is not supported.

If I instead double click the .grist file to open Grist automatically with this file, I get a different error:

Error accessing document You can try reloading the document, or using recovery mode. Recovery mode opens the document to be fully accessible to owners, and inaccessible to others. It also disables formulas. [SQLITE_CANTOPEN: unable to open database file]

Trying to enter recovery mode will show a toast message in the lower left stating

14:01:20 SQLITE_CANTOPEN: unable to open database file.

This also has a nice Report button, but when I click this I get another toast message, saying the report form isn't set up.

[paulfitz]

Thanks for reporting this @ruudschouten, will look into it. Which OS was this? In the meantime, you should be able to find Grist documents sitting on your filesystem as .grist files.

[ruudschouten]

This was on Windows 10; Version 10.0.19045 Build 19045

[nasmi3]

Hi, I saw the same issue on windows. Grist is able to open any .grist file created by making a new doc through the app. However it doesn't work when :

• I make a copy of the .grist file, rename it and try to open it
• Try to open a .grist file created and downloaded a server instance of grist (grist-core)

It might be linked with the fact that the documents have colliding or absent document id in the sqlite (like the home.sqlite for grist-core)

[paulfitz]

@nasmi3 are you also using Windows?

[nasmi3]

Dear Paul, Yes, I am on windows 10 too. I haven't checked on other platforms. Again thank you for your work on this project !

[ianzhuo]

Hi, I saw the same issue on windows. Grist is able to open any .grist file created by making a new doc through the app. However it doesn't work when :

• I make a copy of the .grist file, rename it and try to open it
• Try to open a .grist file created and downloaded a server instance of grist (grist-core)

It might be linked with the fact that the documents have colliding or absent document id in the sqlite (like the home.sqlite for grist-core)

Hi, I I tried to roll back to grist-electron-windows-0.1.8-x64.exe, and then the file opening function back to normal.

[Anamon]

This persists in version 1.1.3.

There seems to be some internal (to the .grist file) or external source which keeps a record of a .grist file's absolute path and filename. It needs to stay absolutely the same, otherwise it can't be opened anymore.

Reproduction steps

1. Create a new file in the app, note the location of the .grist file in the user's directory.
2. Close grist-electron.
3. Change some letter in the filename of the .grist file.
4. Try to open the .grist file in grist-electron.
5. Close grist-electron.
6. Change the name of the .grist file back to the original name.
7. Open the .grist file again in grist-electron.

In step 4, you will get the SQLITE_CANTOPEN error when trying to open the file. In step 7, after restoring the original filename, the file opens properly again. So there is obviously nothing wrong with the file itself (other applications can also open it as an SQLite3 file without issues).

On a quick check, I couldn't find a reference to the filename in the .grist file, nor the grist-electron application data directory, though. So I'm not sure where grist-electron is getting the information on what the file has to be called.

[paulfitz]

Hi @Anamon, the interaction between the Electron version of Grist and the file system is super primitive: https://github.com/gristlabs/grist-electron/blob/04a8fc54d22d8d571d97bddcc1545c0fe40f5c59/ext/app/electron/main.ts#L188-L200 Basically, it is using a simple hack to adapt the server version of Grist (which has full control of where files are stored) to the desktop. The server version expects to have a little entry for each file in a database, so we make one to keep it happy. This could definitely be improved!

[jyio]

Greetings. I'm seeing similar behavior in release 0.2.8 on Windows 10 when attempting to open a *.grist file from the filesystem,

Error accessing document You can try reloading the document, or using recovery mode. Recovery mode opens the document to be fully accessible to owners, and inaccessible to others. It also disables formulas. [SQLITE_CANTOPEN: unable to open database file]

It could import the very same file just fine, but of course that results in a new file in %USERPROFILE%\Documents. Now, this file could be opened without error, but a different file copied into %USERPROFILE%\Documents triggers SQLITE_CANTOPEN.

Grist serves me just fine in headless mode, so this is not a deal-breaker for me; but this could make it more difficult to sell Grist to folks who could not set up their own server but still require assurance that they could access their data for years to come (even if the cloud services went offline).

[tbleiker]

Same here with 0.2.9 on Windows 10 and Windows 11. I cannot download a grist project to another folder and open it (SQLITE_CANTOPEN: unable to open database file).

[paulfitz]

@SleepyLeslie do you have any insight into what @tbleiker is seeing? I know we plan to make big changes to how Desktop interacts with the file system to make it more "normal", but even under the limited current adapter I'd have thought opening a Grist file in a folder should work.

[SleepyLeslie]

Confirmed on Windows (only). The issue is with fse.symlink, where Grist Desktop mistakenly specifies the type as "junction". Windows junctions do not require special privileges, but can only work for directories, not files. This could be simply fixed by removing the type parameter and let Node.js infer it (will result in "file" which is correct). However, this won't fix the user experience since Windows requires users to have a special privilege (Local Policies\User Rights Assignment\Create symbolic links) to create symlinks, and we'll just begin to hit permission errors instead.

A plausible workaround is to use shortcuts instead of symlinks. If this is confirmed to work, I'll squeeze the fix into the next release.

EDIT: Shortcuts are not a solution. They are not transparent to upper constructs. Essentially they are .lnk files containing data in a specific format. I think there is no quick workaround here. To make this feature work on Windows properly, we must refactor how Grist Desktop works to stop relying on symlinks.

[SleepyLeslie]

Another plausible ad-hoc fix is to tell users to explicitly grant the "Create symbolic links" permission to themselves, but this has some security implications: https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-vista/cc766301(v=ws.10)?redirectedfrom=MSDN#create-symbolic-links