Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"Level 2 not synchronized" #75

Open
eichin opened this issue Jun 18, 2022 · 6 comments
Open

"Level 2 not synchronized" #75

eichin opened this issue Jun 18, 2022 · 6 comments

Comments

@eichin
Copy link

eichin commented Jun 18, 2022

Just installed from git, ubuntu 22.04, libfuse-dev 2.9.9-5ubuntu3 (but fuse3, 3.10.5-1build1.) 363 open tabs (trying to get away from Workona :-) and one error:

drafting-table$ ls -al fs/mnt/tabs/by-title/ 
/bin/ls: cannot access 'fs/mnt/tabs/by-title/.___Phrack_Magazine____.832': Level 2 not synchronized
...
?????????? ? ?    ?     ?            ?  .___Phrack_Magazine____.832
...

(the rest of the output is fine, it's just this one failing file entry.) Might be notable that this is also the only name in by-title with a leading dot. http://phrack.org/issues/49/14.html should be the page in question, and it has

<title>.:: Phrack Magazine ::.</title>

as the title. Not sure if there's anything else notable about the page beyond "it's almost entirely a single giant <pre> element".

@osnr
Copy link
Owner

osnr commented Jun 19, 2022

Huh. I don't have any ideas off the top of my head, but I should look into this more. Could you make a Web page of your own with a leading dot and see if that also breaks it?

@eichin
Copy link
Author

eichin commented Jun 20, 2022

Good idea. I created /tmp/test.html containing

<html>
  <head>
    <title>.:: test ::.</title>
  </head>
</html>

and open file:///tmp/test.html and now get

  /usr/bin/ls: cannot access '/home/eichin/gits/TabFS/fs/mnt/tabs/by-title/.___test____.4445': Level 2 not synchronized
    ?????????? ? ?    ?     ?            ? .___test____.4445

If I strip it down to .: it still fails; . by itself works as does .x.

@eichin
Copy link
Author

eichin commented Jun 20, 2022

(if it matters this is Google Chrome 102.0.5005.115 (Official Build) (64-bit) as I see I didn't include that in the initial post.)

@eichin
Copy link
Author

eichin commented Jun 20, 2022

strace confirms that the ls is getting an EL2NSYNC, but I don't find reference to that in the fuse sources, or really anywhere but fairly obscure places in the kernel.

97267 statx(AT_FDCWD</home/eichin/tmp/deb>, "/home/eichin/gits/TabFS/fs/mnt/tabs/by-title/._.4445", AT_STATX_SYNC_AS_STAT|AT_SYMLINK_NOFOLLOW, STATX_MODE|STATX_NLINK|STATX_UID|STATX_GID|STATX_MTIME|STATX_SIZE, 0x7ffec4298820) = -1 EL2NSYNC (Level 2 not synchronized)

(That does suggest the kernel matters, so uname -r output for reference: 5.15.0-23-generic )

@eichin
Copy link
Author

eichin commented Jun 20, 2022

Ah! Recalling that errno values are really just numbers... for x86_64 linux, EL2NSYNC is 45. Looking at extension/background.js, though,

const unix = {
...
  ENOTSUP: 45,
...

so that's probably the value that's making it through.

The only reference to that is

function tryMatchRoute(path) {
  if (path.match(/\/\._[^\/]+$/)) {
    // Apple Double ._whatever file for xattrs
    throw new UnixError(unix.ENOTSUP); 
  }

which... is definitely suspicious :-)

@eichin
Copy link
Author

eichin commented Jun 23, 2022

So there are two issues here. The easier one would be that the AppleDouble filtering matches some sanitized paths, that probably just means tweaking sanitize a little.

The trickier one is that errno is platform specific in a way that JavaScript intentionally conceals. If I'm reading this right, the path is that in background.js, onMessage has a try/catch, and if it catches a UnixError puts the error value in response.error. From there, tabfs.c do_exchange looks for {error: %d} with json_scanf and grabs that number.

Suggestion: tabfs.c knows what platform it's on (has a couple of #if defined but more importantly, already includes <errno.h>.) Put a translation there; you could make the unix enumeration in background.js just have a list of values... but I'd go with just having it return text tokens outright - then tabfs can check for strings and return the proper platform-specific errno values. Not a lot of overhead (you're passing JSON messages around anyway) though it is a change in the protocol; if that's a concern, then taking the current numbers and translating them makes more sense.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants