From: Gilad R. <gi...@fa...> - 2008-07-16 12:55:50
|
Hi, I'm currently implementing a network-based file system using FUSE, and I must say that you guys have done a great job! It took me no time at all to get up and running, and now, two days later, my file system <-> FUSE plug-in is almost done. One big issue remains: When i use 'touch' to create a file, I see that FUSE issues a getattr() call, gets a -ENOENT from me, and the proceeds to create the file and verify it's there using an other getattr(). So far so good. When I issue a cp command to copy a file into the FS, I see FUSE run three getattr() calls in a row, and then proceed to run create(), which is immediately followed by release(), presumably because the previous calls to getattr() failed, even though they were called BEFORE create(), so they should have. Obviously, my cp command fails because of that. For example (tmp is the directory mounted using FUSE): $ cp /home/gilad/Manager tmp/newfile13 unique: 2511, opcode: LOOKUP (1), nodeid: 1, insize: 50 LOOKUP /newfile13 getattr: /newfile13 getattr: file not found, return -2 unique: 2511, error: -2 (No such file or directory), outsize: 16 unique: 2512, opcode: LOOKUP (1), nodeid: 1, insize: 50 LOOKUP /newfile13 getattr: /newfile13 getattr: file not found, return -2 unique: 2512, error: -2 (No such file or directory), outsize: 16 unique: 2513, opcode: LOOKUP (1), nodeid: 1, insize: 50 LOOKUP /newfile13 getattr: /newfile13 getattr: file not found, return -2 unique: 2513, error: -2 (No such file or directory), outsize: 16 unique: 2514, opcode: CREATE (35), nodeid: 1, insize: 58 NODEID: 3 release: closing file /newfile13 delete: 3 unique: 2514, error: -5 (Input/output error), outsize: 16 -- END EXAMPLE -- Again, using 'touch' seems to call the functions in the right order, When I try the cp command again, after the file was created, it succeeds. any reason for such contradicting behavior? What am I missing? Using Ubuntu 8.04, stock fuse kernel module and lib. Thanks, Gilad |
From: Nikolaus R. <Nik...@ra...> - 2008-07-16 13:28:15
|
Gilad Rom <gi...@fa...> writes: > When I issue a cp command to copy a file into the FS, I see > FUSE run three getattr() calls in a row, and then proceed to run > create(), which is immediately followed by release(), presumably because > the previous calls to getattr() failed, even though they were called > BEFORE create(), so they should have. Obviously, my cp command fails > because of that. create() creates *and* opens a file. After cp has written the contents, it closes the file, which correctly results in release() being called. There is no connection between the getattr() and the release() call. I guess your fs assumes that create() creates a file without opening it. Hope that helps, -Nikolaus -- »It is not worth an intelligent man's time to be in the majority. By definition, there are already enough people to do that.« -J.H. Hardy PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C |
From: Gilad R. <gi...@fa...> - 2008-07-16 13:35:04
|
On Wed, 2008-07-16 at 15:21 +0200, Nikolaus Rath wrote: > Gilad Rom <gi...@fa...> writes: > > When I issue a cp command to copy a file into the FS, I see > > FUSE run three getattr() calls in a row, and then proceed to run > > create(), which is immediately followed by release(), presumably because > > the previous calls to getattr() failed, even though they were called > > BEFORE create(), so they should have. Obviously, my cp command fails > > because of that. > > create() creates *and* opens a file. After cp has written the > contents, it closes the file, which correctly results in release() > being called. There is no connection between the getattr() and the > release() call. > > I guess your fs assumes that create() creates a file without opening > it. > Actually, it does just that. The network file system has no 'create', so I use open for both open() and create(). Gilad > > Hope that helps, > > -Nikolaus > |
From: Nikolaus R. <Nik...@ra...> - 2008-07-16 14:18:22
|
Gilad Rom <gi...@fa...> writes: > On Wed, 2008-07-16 at 15:21 +0200, Nikolaus Rath wrote: >> Gilad Rom <gi...@fa...> writes: >> > When I issue a cp command to copy a file into the FS, I see >> > FUSE run three getattr() calls in a row, and then proceed to run >> > create(), which is immediately followed by release(), presumably because >> > the previous calls to getattr() failed, even though they were called >> > BEFORE create(), so they should have. Obviously, my cp command fails >> > because of that. >> >> create() creates *and* opens a file. After cp has written the >> contents, it closes the file, which correctly results in release() >> being called. There is no connection between the getattr() and the >> release() call. >> >> I guess your fs assumes that create() creates a file without opening >> it. > > Actually, it does just that. The network file system has no > 'create', so I use open for both open() and create(). In that case I don't quite understand your description above: >>> the previous calls to getattr() failed, even though they were called >>> BEFORE create(), so they should have. What should have (done?) what? >>> Obviously, my cp command fails because of that. Because of what, exactly? To me the error message looks as if either the release() or some subsequent call returns an error. Could you check which function is called last before the "unique: 2514, error: -5 (Input/output error), outsize: 16" line appears and what value it returns? Best, -Nikolaus -- »It is not worth an intelligent man's time to be in the majority. By definition, there are already enough people to do that.« -J.H. Hardy PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C |
From: Gilad R. <gi...@fa...> - 2008-07-16 14:36:56
|
On Wed, 2008-07-16 at 16:08 +0200, Nikolaus Rath wrote: > Gilad Rom <gi...@fa...> writes: > > On Wed, 2008-07-16 at 15:21 +0200, Nikolaus Rath wrote: > >> Gilad Rom <gi...@fa...> writes: > >> > When I issue a cp command to copy a file into the FS, I see > >> > FUSE run three getattr() calls in a row, and then proceed to run > >> > create(), which is immediately followed by release(), presumably because > >> > the previous calls to getattr() failed, even though they were called > >> > BEFORE create(), so they should have. Obviously, my cp command fails > >> > because of that. > >> > >> create() creates *and* opens a file. After cp has written the > >> contents, it closes the file, which correctly results in release() > >> being called. There is no connection between the getattr() and the > >> release() call. > >> > >> I guess your fs assumes that create() creates a file without opening > >> it. > > > > Actually, it does just that. The network file system has no > > 'create', so I use open for both open() and create(). > > In that case I don't quite understand your description above: > >>> the previous calls to getattr() failed, even though they were called > >>> BEFORE create(), so they should have. > > What should have (done?) what? > What I mean is that the getattr() calls all return -ENOENT, as they should, since the file is not there and has not been created yet. > >>> Obviously, my cp command fails because of that. > > Because of what, exactly? > 1. fuse calls getattr() 3 times in a row 2. fuse calls create() 3. fuse SHOULD call getattr() again, but calls delete 4. cp fails #3 is what I don't understand. The create() function in #2 works normally, and returns 0. Why is delete() called right after? What I _think_ is happening is that create(), for some reason, is called AFTER the getattr() call which should have been there to verify the new file's existence, so getattr() returns an error, because create() has not been called yet. Is that better? ;) Why is getattr() called 3 times in a row instead of once, and why is it not called after create() ? again, the behavior I see when I touch a file is: 1. fuse calls getattr() once 2. fuse calls create() 3. fuse calls getattr() once more Which is perfectly fine. Thanks, Gilad |
From: Nikolaus R. <Nik...@ra...> - 2008-07-16 17:28:08
|
Gilad Rom <gi...@fa...> writes: >> >>> Obviously, my cp command fails because of that. >> >> Because of what, exactly? >> > > 1. fuse calls getattr() 3 times in a row > 2. fuse calls create() > 3. fuse SHOULD call getattr() again, but calls delete > 4. cp fails > > #3 is what I don't understand. The create() function in #2 works > normally, and returns 0. Why is delete() called right after? Do you actually have a function called delete() that is called by fuse? If so, what does it do? According to the CVS fuse.h, there is no such function. > What I _think_ is happening is that create(), for some reason, is > called AFTER the getattr() call which should have been there to > verify the new file's existence, so getattr() returns an error, > because create() has not been called yet. Is that better? ;) Yes, but I think you're wrong. After all, you're not getting ENOENT but EIO. Could you please check the return code of the last function that is called by fuse? (Either release() or the delete function that is unknown to me) > Why is getattr() called 3 times in a row instead of once, This is most likely because some calls are generated by cp itself. Best, -Nikolaus -- »It is not worth an intelligent man's time to be in the majority. By definition, there are already enough people to do that.« -J.H. Hardy PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C |
From: Allen P. <pul...@co...> - 2008-07-16 17:34:35
|
There are a long list of FUSE-based file systems that work, and none of them have a problem with cp. It would seem pretty straightforward to test one of these file system to see what should be happening during a cp. |
From: Gilad R. <gi...@fa...> - 2008-07-16 18:12:00
|
On Wed, 2008-07-16 at 13:34 -0400, Allen Pulsifer wrote: > There are a long list of FUSE-based file systems that work, and none of them > have a problem with cp. It would seem pretty straightforward to test one of > these file system to see what should be happening during a cp. > This problem is not cp specific, but happens every single time I try to write to a file that does not exist (thus creating it in the process), whereas simply creating a file using touch works fine. The funny thing is that the exact same functions are called both times and return the same values... Gilad > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > fuse-devel mailing list > fus...@li... > https://lists.sourceforge.net/lists/listinfo/fuse-devel |
From: Allen P. <pul...@co...> - 2008-07-16 18:47:34
|
> This problem is not cp specific, but happens every single > time I try to write to a file that does not exist (thus > creating it in the process), whereas simply creating a file > using touch works fine. It might not be cp specific, but it is definitely specific to your file system. If you had tried comparing your file system to one that works, you would probably have this fixed already. |
From: Gilad R. <gi...@fa...> - 2008-07-16 17:45:39
|
On Wed, 2008-07-16 at 19:24 +0200, Nikolaus Rath wrote: > Gilad Rom <gi...@fa...> writes: > >> >>> Obviously, my cp command fails because of that. > >> > >> Because of what, exactly? > >> > > > > 1. fuse calls getattr() 3 times in a row > > 2. fuse calls create() > > 3. fuse SHOULD call getattr() again, but calls delete > > 4. cp fails > > > > #3 is what I don't understand. The create() function in #2 works > > normally, and returns 0. Why is delete() called right after? > > Do you actually have a function called delete() that is called by > fuse? If so, what does it do? According to the CVS fuse.h, there is no > such function. > No, the function's name is release(). Sorry for the confusion. > > What I _think_ is happening is that create(), for some reason, is > > called AFTER the getattr() call which should have been there to > > verify the new file's existence, so getattr() returns an error, > > because create() has not been called yet. Is that better? ;) > > Yes, but I think you're wrong. After all, you're not getting ENOENT > but EIO. Could you please check the return code of the last function > that is called by fuse? (Either release() or the delete function that > is unknown to me) > Yeah, that's the problem right there. I dont have a single line of code that returns -EIO. They all either return 0 or -ENOENT. read() returns the number of bytes read, but that's not a problem, since it is never called in this context. and create() returns -EACCES if it fails, which is not the case, since it succeeds every time. (I'm left with a zero byte file after the command fails. If I run it again, everything works) I've verified that both create() and release() return 0 using gdb breakpoints. > > > Why is getattr() called 3 times in a row instead of once, > > This is most likely because some calls are generated by cp itself. > True, using "echo hi > somefile" looks better, but still fails. > > Best, > > -Nikolaus > |
From: Nikolaus R. <Nik...@ra...> - 2008-07-16 18:38:10
|
Gilad Rom <gi...@fa...> writes: >> > What I _think_ is happening is that create(), for some reason, is >> > called AFTER the getattr() call which should have been there to >> > verify the new file's existence, so getattr() returns an error, >> > because create() has not been called yet. Is that better? ;) >> >> Yes, but I think you're wrong. After all, you're not getting ENOENT >> but EIO. Could you please check the return code of the last function >> that is called by fuse? (Either release() or the delete function that >> is unknown to me) >> > > Yeah, that's the problem right there. I dont have a single line > of code that returns -EIO. They all either return 0 or -ENOENT. > read() returns the number of bytes read, but that's not a problem, > since it is never called in this context. > > and create() returns -EACCES if it fails, which is not the case, > since it succeeds every time. (I'm left with a zero byte file > after the command fails. If I run it again, everything works) > > I've verified that both create() and release() return 0 using gdb > breakpoints. As Allen already said, this is still most likely a bug in your implementation. What happens if you don't define a create function at all, and let fuse call mknod and open instead? Best, -Nikolaus -- »It is not worth an intelligent man's time to be in the majority. By definition, there are already enough people to do that.« -J.H. Hardy PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C |
From: Gilad R. <gi...@fa...> - 2008-07-17 09:43:37
|
On Wed, 2008-07-16 at 20:33 +0200, Nikolaus Rath wrote: > What happens if you don't define a create function at all, and let > fuse call mknod and open instead? > Now everything works as expected... I simply pasted the code from my create() function (and added some code to close the file right after creating it, since open() is called next), and fuse is happy and reports no errors. Is this the "right" way to do things, or should I still try to implement create()? is there a down side to using mknod+open instead? I'm not worried about file creation times, as this file system will be mostly used for massive parallel read/writes without many new files added at a time. Thanks! Gilad > Best, > > -Nikolaus > |
From: Miklos S. <mi...@sz...> - 2008-07-19 10:39:26
|
On Fri, 18 Jul 2008, Dave Ingram wrote: > Essentially, the way to import files into my file system is by creating > absolute symlinks (so that I can keep a reference to the file rather > than duplicating/storing its data), but these links then show up as > regular files in directory listings, with the attributes etc of the > files they refer to. This (I assume) causes FUSE to return EIO to the > caller, when I'd prefer it to stay quiet about my misdirection. > > Any suggestions? Set the timeouts to zero ("-oattr_timeout=0,entry_timeout=0"), return the symlink type for the first time ->getattr() is called, and regular file next time. The side effect is: no caching. You could fix that by using the low level interface, since there each individual lookup can have different timeouts. Miklos |
From: Nikolaus R. <Nik...@ra...> - 2008-07-17 11:38:09
|
Hello, ,---- | On Wed, 2008-07-16 at 20:33 +0200, Nikolaus Rath wrote: | > What happens if you don't define a create function at all, and let | > fuse call mknod and open instead? | > | | Now everything works as expected... I simply pasted the code from my | create() function (and added some code to close the file right after | creating it, since open() is called next), and fuse is happy and reports | no errors. So what happens if you define a create function that *only* calls mknod() and open()? | | Is this the "right" way to do things, or should I still try to implement | create()? is there a down side to using mknod+open instead? That's an alternative way to do things, but using create() should work just as well. Best, -Nikolaus -- »It is not worth an intelligent man's time to be in the majority. By definition, there are already enough people to do that.« -J.H. Hardy PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C |
From: Miklos S. <mi...@sz...> - 2008-07-18 12:31:44
|
On Thu, 17 Jul 2008, Nikolaus Rath wrote: > | > | Is this the "right" way to do things, or should I still try to implement > | create()? is there a down side to using mknod+open instead? > > That's an alternative way to do things, but using create() should work > just as well. Right. The EIO is caused by ->getattr() not returning a correct st_mode value, i.e. S_ISREG(buf.st_mode) fails. (Yeah, I know, should be better ducumented ;) Miklos |
From: Nikolaus R. <Nik...@ra...> - 2008-07-18 16:38:03
|
Miklos Szeredi <mi...@sz...> writes: > On Thu, 17 Jul 2008, Nikolaus Rath wrote: >> | >> | Is this the "right" way to do things, or should I still try to implement >> | create()? is there a down side to using mknod+open instead? >> >> That's an alternative way to do things, but using create() should work >> just as well. > > Right. > > The EIO is caused by ->getattr() not returning a correct st_mode > value, i.e. S_ISREG(buf.st_mode) fails. > > (Yeah, I know, should be better ducumented ;) If can explain it to me, I may provide another patch :-). >From what function is EIO returned if S_ISREG fails? I didn't quite get it... Best, -Nikolaus -- »It is not worth an intelligent man's time to be in the majority. By definition, there are already enough people to do that.« -J.H. Hardy PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C |
From: Miklos S. <mi...@sz...> - 2008-07-18 16:51:21
|
On Fri, 18 Jul 2008, Nikolaus Rath wrote: > Miklos Szeredi <mi...@sz...> writes: > > On Thu, 17 Jul 2008, Nikolaus Rath wrote: > >> | > >> | Is this the "right" way to do things, or should I still try to implement > >> | create()? is there a down side to using mknod+open instead? > >> > >> That's an alternative way to do things, but using create() should work > >> just as well. > > > > Right. > > > > The EIO is caused by ->getattr() not returning a correct st_mode > > value, i.e. S_ISREG(buf.st_mode) fails. > > > > (Yeah, I know, should be better ducumented ;) > > If can explain it to me, I may provide another patch :-). > > > From what function is EIO returned if S_ISREG fails? I didn't quite > get it... Sorry, I'll try again :) Fuse will return EIO if the filesystem did something contradictory. More specifically, here libfuse will return EIO (to the original open(O_CREAT) or create() syscalls), if after calling the ->create() method, and then calling the ->getattr() method, the returned file type in st_mode is not a regular file. Miklos |
From: Dave I. <da...@dm...> - 2008-07-18 17:00:45
|
Miklos Szeredi wrote: > On Fri, 18 Jul 2008, Nikolaus Rath wrote: >> Miklos Szeredi <mi...@sz...> writes: >>> The EIO is caused by ->getattr() not returning a correct st_mode >>> value, i.e. S_ISREG(buf.st_mode) fails. >>> >>> (Yeah, I know, should be better ducumented ;) >> If can explain it to me, I may provide another patch :-). >> >> >> From what function is EIO returned if S_ISREG fails? I didn't quite >> get it... > > Sorry, I'll try again :) > > Fuse will return EIO if the filesystem did something contradictory. > > More specifically, here libfuse will return EIO (to the original > open(O_CREAT) or create() syscalls), if after calling the ->create() > method, and then calling the ->getattr() method, the returned file > type in st_mode is not a regular file. Not completely related, but is there any way I can bypass this? At the moment, my file system does some odd things that are quite inconsistent, and I'd prefer to just let it pass FUSE without errors, if possible. I had assumed that it was ln that was having the trouble. Essentially, the way to import files into my file system is by creating absolute symlinks (so that I can keep a reference to the file rather than duplicating/storing its data), but these links then show up as regular files in directory listings, with the attributes etc of the files they refer to. This (I assume) causes FUSE to return EIO to the caller, when I'd prefer it to stay quiet about my misdirection. Any suggestions? Dave PS: apologies for the double post earlier about the C HOWTO... my email client crashed partway through the send, and seems to have sent it a second time! |
From: Gilad R. <gi...@fa...> - 2008-07-20 07:22:23
|
On Fri, 2008-07-18 at 18:51 +0200, Miklos Szeredi wrote: > On Fri, 18 Jul 2008, Nikolaus Rath wrote: > > Miklos Szeredi <mi...@sz...> writes: > > > On Thu, 17 Jul 2008, Nikolaus Rath wrote: > > >> | > > >> | Is this the "right" way to do things, or should I still try to implement > > >> | create()? is there a down side to using mknod+open instead? > > >> > > >> That's an alternative way to do things, but using create() should work > > >> just as well. > > > > > > Right. > > > > > > The EIO is caused by ->getattr() not returning a correct st_mode > > > value, i.e. S_ISREG(buf.st_mode) fails. > > > > > > (Yeah, I know, should be better ducumented ;) > > > > If can explain it to me, I may provide another patch :-). > > > > > > From what function is EIO returned if S_ISREG fails? I didn't quite > > get it... > > Sorry, I'll try again :) > > Fuse will return EIO if the filesystem did something contradictory. > > More specifically, here libfuse will return EIO (to the original > open(O_CREAT) or create() syscalls), if after calling the ->create() > method, and then calling the ->getattr() method, the returned file > type in st_mode is not a regular file. > That's the thing - I couldn't see a getattr() call after create(). It looked as though the create() itself has failed, even though I returned 0... Gilad |
From: Nikolaus R. <Nik...@ra...> - 2008-07-19 09:38:07
|
Miklos Szeredi <mi...@sz...> writes: > Fuse will return EIO if the filesystem did something contradictory. Hmm. I couldn't find a good place for this piece of information in the distribution, so I have added it to the Wiki. > More specifically, here libfuse will return EIO (to the original > open(O_CREAT) or create() syscalls), if after calling the ->create() > method, and then calling the ->getattr() method, the returned file > type in st_mode is not a regular file. Is there a particular reason why fuse calls getattr() after the create()? Why doesn't it trust the return value of the create() request to determine if everything worked fine? Does fuse do this for all kind of requests (e.g. also for link(), symlink() or chmod())? Best, -Nikolaus -- »It is not worth an intelligent man's time to be in the majority. By definition, there are already enough people to do that.« -J.H. Hardy PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C |
From: Miklos S. <mi...@sz...> - 2008-07-19 11:20:34
|
On Sat, 19 Jul 2008, Nikolaus Rath wrote: > Is there a particular reason why fuse calls getattr() after the > create()? Why doesn't it trust the return value of the create() > request to determine if everything worked fine? > > Does fuse do this for all kind of requests (e.g. also for link(), > symlink() or chmod())? Yes, after creating any object. It does the getattr, so it can cache the attributes (ownership, timestamps, etc.) immediately after lookup. So it's basically just an optimization, but one that currently can't be turned off ;) Miklos |
From: Miklos S. <mi...@sz...> - 2008-07-23 09:01:50
|
On Sun, 20 Jul 2008, Gilad Rom wrote: > On Fri, 2008-07-18 at 18:51 +0200, Miklos Szeredi wrote: > > More specifically, here libfuse will return EIO (to the original > > open(O_CREAT) or create() syscalls), if after calling the ->create() > > method, and then calling the ->getattr() method, the returned file > > type in st_mode is not a regular file. > > > > > That's the thing - I couldn't see a getattr() call after create(). > It looked as though the create() itself has failed, even though > I returned 0... getattr() *or* fgetattr(). One of them must have been called if create() succeeded. Miklos |
From: Gilad R. <gi...@fa...> - 2008-07-23 12:21:11
|
Ok... let me rephrase that: Is there a reason for create() to fail, even if it returned 0 ? Gilad On Wed, 2008-07-23 at 11:01 +0200, Miklos Szeredi wrote: > On Sun, 20 Jul 2008, Gilad Rom wrote: > > On Fri, 2008-07-18 at 18:51 +0200, Miklos Szeredi wrote: > > > More specifically, here libfuse will return EIO (to the original > > > open(O_CREAT) or create() syscalls), if after calling the ->create() > > > method, and then calling the ->getattr() method, the returned file > > > type in st_mode is not a regular file. > > > > > > > > > That's the thing - I couldn't see a getattr() call after create(). > > It looked as though the create() itself has failed, even though > > I returned 0... > > getattr() *or* fgetattr(). One of them must have been called if > create() succeeded. > > Miklos |
From: Miklos S. <mi...@sz...> - 2008-07-23 17:08:06
|
On Wed, 23 Jul 2008, Gilad Rom wrote: > Ok... let me rephrase that: > > Is there a reason for create() to fail, even if it returned > 0 ? Yes, but only _after_ calling fgetattr() or getattr(), and only if those either returned an error, or they returned an invalid st_mode value. I pretty sure that it was the latter that caused CREATE to return EIO in your case: | unique: 2514, opcode: CREATE (35), nodeid: 1, insize: 58 | NODEID: 3 | release: closing file /newfile13 | delete: 3 | unique: 2514, error: -5 (Input/output error), outsize: 16 Miklos |
From: Gilad R. <gi...@fa...> - 2008-07-24 16:51:36
|
Ok - solved. After stepping using GDB, fgetattr() is indeed called, but is not printed as an opcode.... That was the confusing part ;) (might want to fix that?!) Thanks! -- Gilad On Wed, 2008-07-23 at 19:08 +0200, Miklos Szeredi wrote: > On Wed, 23 Jul 2008, Gilad Rom wrote: > > Ok... let me rephrase that: > > > > Is there a reason for create() to fail, even if it returned > > 0 ? > > Yes, but only _after_ calling fgetattr() or getattr(), and only if > those either returned an error, or they returned an invalid st_mode > value. I pretty sure that it was the latter that caused CREATE to > return EIO in your case: > > | unique: 2514, opcode: CREATE (35), nodeid: 1, insize: 58 > | NODEID: 3 > | release: closing file /newfile13 > | delete: 3 > | unique: 2514, error: -5 (Input/output error), outsize: 16 > > Miklos |