IDBFS not persistent ?

[Guillaume Leclerc]

Hello,

I was trying to use IDBFS but I can't get it to be persistent.

I run the following in the console (of firefox)

FS.mkdir("/test");
FS.mount(IDBFS, {}, "/test");
FS.syncfs(true, console.log.bind(console));
//wait the callback to be called
FS.mkdir("/test/test2");
FS.syncfs(true, console.log.bind(console));
//wait the callback to be called
// reload the page
FS.mkdir("/test");
FS.mount(IDBFS, {}, "/test");
FS.syncfs(true, console.log.bind(console));
//wait the callback to be called
FS.readdir("/test");
// ==> Outputs ["..", "."]

Im I doing something wrong ?
Is it because It is local html file (maybe I must use a web-server)

Thank you for your help

[Alon Zakai]

Definitely try a local server, like    python -m SimpleHTTPServer     , because file:/// URLs might not allow IDB access.

Another thing that might be useful is to look at the IDBFS examples in the test suite, which are known to work.

--
You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-disc...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Guillaume Leclerc]

Thank you,

It worked with a local web server (nginx).

I modified a file manager to work with emscripten file system API. But some times (every hour approximately) the content of IDBFS is completely deleted. Does anyone faced this problem ?

Best regards,

Guillaume Leclerc

[Woof]

On Wednesday, 29 July 2015 14:12:14 UTC+2, Guillaume Leclerc wrote:

But some times (every hour approximately) the content of IDBFS is completely deleted. Does anyone faced this problem ?

 
IndexedDB isn't currently (AFAIK) using persistent storage, so will be purged at some point. In use though I haven't seen this happen unless I've cleared the data myself. I did try using the persistent storage with the FileSystem API but I found the quota request was putting users off (a big scary pop-up from the browser, which users were declining).

Carl

[キャロウ マーク]

> On Jul 30, 2015, at 1:56 AM, Woof <cwoff...@gmail.com> wrote:
>
> IndexedDB isn't currently (AFAIK) using persistent storage, so will be purged at some point. In use though I haven't seen this happen unless I've cleared the data myself. I did try using the persistent storage with the FileSystem API but I found the quota request was putting users off (a big scary pop-up from the browser, which users were declining).
>

This is a little off topic but …

The above is a fairly typical developer reaction to browser’s popping requests for permission. The implication being that they wish there wasn’t a pop-up. Developers can remove the “scary” part by, raising a message box themselves before executing the call that pops up the browser permission request. In this message box they can explain why the application needs the permission. In this case it would explain what data is going to be saved in persistent storage and the benefit of doing do. Doing this will greatly improve the chances of your user giving permission.

At least browsers request permissions one by one so applications can provide explanations before the request appears. This is not possible with Android’s completely broken all-or-nothing permission system.

Regards

-Mark

[Woof]

Have you ever seen the message Chrome, for example, shows for a quota request? Something along the lines of "this website is attempting to store more than x MB of data". To the uninitiated it *is* scary. The website is "attempting" to do something to your computer. Showing another message box before this one isn't going to solve anything:

    "Now then, gentle user, your browser's going to ask you to do something strange, but you must say yes. Trust me."

That'll work. Typical developer reaction to solving showing one message box by showing two.

What we did is use the temporary storage, which doesn't require any permissions, and so doesn't show a message (or two). In testing the temporary IndexedDB (and FileSystem API) appears to have been permanent enough, with any data to be stored permanently done so on the server. So no messages popping up and happy users.

Carl

[キャロウ マーク]

On Jul 30, 2015, at 12:59 PM, Woof <cwoff...@gmail.com> wrote:

Have you ever seen the message Chrome, for example, shows for a quota request? Something along the lines of "this website is attempting to store more than x MB of data". To the uninitiated it *is* scary. The website is "attempting" to do something to your computer. Showing another message box before this one isn't going to solve anything:

    "Now then, gentle user, your browser's going to ask you to do something strange, but you must say yes. Trust me."

That'll work. Typical developer reaction to solving showing one message box by showing two.

What we did is use the temporary storage, which doesn't require any permissions, and so doesn't show a message (or two). In testing the temporary IndexedDB (and FileSystem API) appears to have been permanent enough, with any data to be stored permanently done so on the server. So no messages popping up and happy users.

This is not the place for further discussion on this topic so I’ll just say “it works." See http://techcrunch.com/2014/04/04/the-right-way-to-ask-users-for-ios-permissions/.  One way to guarantee it doesn’t work though is to use emotive content-free messages such as the one you propose.

Regards

    -Mark