syncFileSystem failing on getFile()

[Thomas Wilburn]

I'm switching some storage from chrome.storage.sync over to chrome.syncFileSystem for size reasons, and I'm having a little trouble getting it to work. I can successfully request the filesystem, but once I have it, the following call fails with an Encoding Error, which the HTML5 filesystem API docs say means that the path was invalid. 

fs.root.getFile("test.txt", {create: true}, gotFile, gotError);

The documentation for syncFileSystem, and the sample code, seems to have fallen a bit behind, and examples are thin on the ground. Is there some different way I need to pass the path in so that it won't be rejected, or do I have another problem?

[Kinuko Yasuda]

Hi,

On Tue, Dec 3, 2013 at 4:56 PM, Thomas Wilburn <sombrad...@gmail.com> wrote:

I'm switching some storage from chrome.storage.sync over to chrome.syncFileSystem for size reasons, and I'm having a little trouble getting it to work. I can successfully request the filesystem, but once I have it, the following call fails with an Encoding Error, which the HTML5 filesystem API docs say means that the path was invalid. 

fs.root.getFile("test.txt", {create: true}, gotFile, gotError);

Does the problem always happen? Would you be able to try relaunching Chrome and see if it still happens?  I think I've seen similar error before but I couldn't repro after relaunching.

The documentation for syncFileSystem, and the sample code, seems to have fallen a bit behind, and examples are thin on the ground. Is there some different way I need to pass the path in so that it won't be rejected, or do I have another problem?

Your code looks fine to me.  I've tested the following code snippet (which must be mostly same as yours) and it worked fine for me (and the file's successfully sync'ed):

var filesystem, entry;

chrome.syncFileSystem.requestFileSystem(function(fs) { filesystem = fs; });

filesystem.root.getFile("test.txt", {create:true}, function(e) { entry = e }, function(e) { console.log(e) });

If the problem sticks around (even with the code above) it'd be helpful if you could file a bug.  Thanks,

--
You received this message because you are subscribed to the Google Groups "Chromium Apps" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-app...@chromium.org.
To post to this group, send email to chromi...@chromium.org.
Visit this group at http://groups.google.com/a/chromium.org/group/chromium-apps/.
For more options, visit https://groups.google.com/a/chromium.org/groups/opt_out.

[Kinuko Yasuda]

On Tue, Dec 3, 2013 at 5:50 PM, Kinuko Yasuda <kin...@chromium.org> wrote:

Hi,

On Tue, Dec 3, 2013 at 4:56 PM, Thomas Wilburn <sombrad...@gmail.com> wrote:

I'm switching some storage from chrome.storage.sync over to chrome.syncFileSystem for size reasons, and I'm having a little trouble getting it to work. I can successfully request the filesystem, but once I have it, the following call fails with an Encoding Error, which the HTML5 filesystem API docs say means that the path was invalid. 

fs.root.getFile("test.txt", {create: true}, gotFile, gotError);

Does the problem always happen? Would you be able to try relaunching Chrome and see if it still happens?  I think I've seen similar error before but I couldn't repro after relaunching.

The documentation for syncFileSystem, and the sample code, seems to have fallen a bit behind, and examples are thin on the ground. Is there some different way I need to pass the path in so that it won't be rejected, or do I have another problem?

Your code looks fine to me.  I've tested the following code snippet (which must be mostly same as yours) and it worked fine for me (and the file's successfully sync'ed):

var filesystem, entry;

chrome.syncFileSystem.requestFileSystem(function(fs) { filesystem = fs; });

filesystem.root.getFile("test.txt", {create:true}, function(e) { entry = e }, function(e) { console.log(e) });

(Just to be more specific, I've manually run the above code in the DevTools console, otherwise callbacks would need to be chained)

[Thomas Wilburn]

Restarting the device fixed the problem, but that's kind of a crappy bug to run into, especially since it's part of an app upgrade and so I really need it to succeed the first time. Is there a trigger or something I can do to keep users from encountering the same problem?

Thomas

[Thomas Wilburn]

Okay, having fought with this for a while today, I have some additional questions:

1) Currently, it looks like the first time this is called, if the device is not online the call will fail to get a file system, returning null and a "File Error -1." on chrome.runtime.lastError. Setting aside the fact that it's an extremely undescriptive error message, this is fine for now, because I'm calling it from inside a chrome.runtime.onInstalled listener, and I can assume that the user was online in order to install. Longer-term, that won't be the case--people may not actually start the app right after installing it, so they may lose connectivity. Is it possible to get a filesystem right away, whether or not the device has connectivity?

2) I'm still seeing some weird errors with users when I try to roll this out just for backups, to the point where I'm not entirely comfortable relying on it for actual functionality. It seems like on some machines, across multiple operating systems, the callbacks aren't ever actually called for requestFileSystem, and I'm not sure why. I didn't have time to check on chrome://syncfs-internals, so I'll try to get more information. Are you aware of any caveats I should watch out for when using these APIs, or that might be causing the callback to fail to fire?

Thomas

[Kinuko Yasuda]

Reg: URI encoding error, I've experienced this once for past 6+ months (and yours is the second time I've heard this), and wasn't sure if it was a real problem.  Looks like it's a real bug, I've filed a bug so that this can be tracked: http://crbug.com/325588.  Thanks for reporting and sorry for the inconveniences.

On Wed, Dec 4, 2013 at 11:18 AM, Thomas Wilburn <sombrad...@gmail.com> wrote:

Okay, having fought with this for a while today, I have some additional questions:

1) Currently, it looks like the first time this is called, if the device is not online the call will fail to get a file system, returning null and a "File Error -1." on chrome.runtime.lastError. Setting aside the fact that it's an extremely undescriptive error message, this is fine for now, because I'm calling it from inside a chrome.runtime.onInstalled listener, and I can assume that the user was online in order to install. Longer-term, that won't be the case--people may not actually start the app right after installing it, so they may lose connectivity. Is it possible to get a filesystem right away, whether or not the device has connectivity?

It is possible to get a local filesystem, but at the time the system cannot make sure if it can really sync its data via Cloud (Drive) when it becomes online.  It could just continue to be in a 'detached' state forever and never sync data if that happens, but we were afraid that could be confusing, so the current version requires the device to be online only for the first time.

(Separately we'll definitely improve the error messages)

2) I'm still seeing some weird errors with users when I try to roll this out just for backups, to the point where I'm not entirely comfortable relying on it for actual functionality. It seems like on some machines, across multiple operating systems, the callbacks aren't ever actually called for requestFileSystem, and I'm not sure why. I didn't have time to check on chrome://syncfs-internals, so I'll try to get more information. Are you aware of any caveats I should watch out for when using these APIs, or that might be causing the callback to fail to fire?

This sounds weird, let us look into this. (Filed another tracking issue for this: http://crbug.com/325602)

If you have some data about what percentage of users are seeing this issue that might be helpful.

[Thomas Wilburn]

Thanks, that's very helpful. If I can, I'll try to get access to the syncfs-internals logs tomorrow on the machine where I can reproduce the callback failure, but I've already removed the code from the web store so it may be a bit of a race to beat the update.

I can understand where creating a detached file system might be confusing, but it would be nice to have a way to handle this more directly, or a way that I can test for that state and handle it (perhaps by re-requesting when the network is available). I'm trying to write for "offline first," and if I can't rely on syncFileSystem to work regardless of connection state in the first call, it's probably going to be impossible to use because there's no viable fallback (short of opening an HTML5 filesystem and manually doing the caching/transfer to Drive at a later time, which is not a road I really want to explore).

If I have to, I'll drop the sync and just use the sandboxed filesystem, but I think users really like having their settings synchronized, and I'd like to keep it as an option.

Thomas

[Kinuko Yasuda]

Follow-up for EncodingError, we think we've found a possible cause, which was a regression (and that's why it wasn't happening previously). We'll fix it and keep watching if it doesn't reproduce.  It's sad that we shipped this bug, but thanks for reporting this anyway, we'd have missed it otherwise.

On Wed, Dec 4, 2013 at 2:41 PM, Thomas Wilburn <sombrad...@gmail.com> wrote:

Thanks, that's very helpful. If I can, I'll try to get access to the syncfs-internals logs tomorrow on the machine where I can reproduce the callback failure, but I've already removed the code from the web store so it may be a bit of a race to beat the update.

I can understand where creating a detached file system might be confusing, but it would be nice to have a way to handle this more directly, or a way that I can test for that state and handle it (perhaps by re-requesting when the network is available). I'm trying to write for "offline first," and if I can't rely on syncFileSystem to work regardless of connection state in the first call, it's probably going to be impossible to use because there's no viable fallback (short of opening an HTML5 filesystem and manually doing the caching/transfer to Drive at a later time, which is not a road I really want to explore).

Makes sense.  I have to say we wouldn't be able to make it work like that in a short term, but we'll consider if returning local-only syncFileSystem first and enabling the sync feature lazily is viable in the current or future design.

Thanks!

[Thomas Wilburn]

Following up on the lack of a callback, I've double-checked the code and it was a user error--I was failing to account for a case where a loop didn't run. I'll go ahead and leave a note on the bug. Sorry for the trouble.

That said, if there's a tracking bug for being able to immediately get a local-only syncFileSystem when offline, I'd love to be able to subscribe to it. In the absence of that feature, I think I'm going to end up hacking something together on top of storage.sync, and just try to keep the code portable enough that I can migrate over to syncFileSystem when it would work for me.

Thomas