Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am trying to test my FUSE file system with TUXERA test suite and I am noticing an issue when testing chown.

One of the test cases is: "chown . 65535 65535", and it expects the test case to pass.

I get this error message: "chown: cannot access `65535': No such file or directory"

This isn't an error I handle in my FS so I can concluded that bash is choking on this statement before even giving it to my FS. I am unsure why it skips over the "." but to confirm this error I made a random folder outside of the FS in question and tried again. The same error arose.

Since I hardly ever use "chown" I can't really tell if the statement is correct or not :/ .


share|improve this question

migrated from Jun 14 '11 at 4:27

This question came from our site for professional and enthusiast programmers.

The syntax is wrong. As it is, it's changing the ownership of a filename of "65535". Twice. And it's actually not changing it since neither the user nor group is specified. Perhaps you meant chown 65535:65535 .?

share|improve this answer
But this test case is straight from a test suite ( and the test suite claims to be a stable release. I have not altered the statement at all. – user761138 Jun 13 '11 at 15:43
But this is their 4th iteration of their test suite, you think they would have at least checked once to confirm the tests were correct. – user761138 Jun 13 '11 at 15:52
up vote 1 down vote accepted

The syntax of chown is wrong, according to the Linux man page for chown (man chown).

A correct form of the command would be:

chown 65535:65535 .

Secondly, "bash" does not interpret this command. It invokes the executable called "chown" and that command handles it.

share|improve this answer
Instead of going through all 3000+ regression tests they set up and checking that chown was implemented correctly, any suggestions about a FS test suite that you would endorse? I kind of went out on a limb to say "bash". This is my first time digging deep into Linux and filesystems. I'm not fully sure how all the parts work together. I was just incorrectly blanketing the fact that whatever happened before the parsed values are sent to the fuse-python chown, was choking on the input. – user761138 Jun 13 '11 at 15:59
I don't know of any FS test suites. However, instead of changing the suite, you could implement a bash script called "chown" that accepts the arguments passed by the test suite and reorders them to send to the real Linux chown. To do this, you'd have to place your "fake" chown in the PATH before /bin/chown and make sure your script invokes /bin/chown when it wants to call the real one. – David Jun 13 '11 at 16:06
Sounds like a good idea. I don't believe I will have to do anything about changing the PATH of the fuse-python chown as it should automatically override the call if you're in the fuse mounted FS. – user761138 Jun 13 '11 at 16:07

Without any option keywords, I'd say this can only mean user=., group=65535, and file=65535. So if that file doesn't exist, the command should fail like you describe.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.