On Sat, 8 Mar 2008, Bernhard Kaindl wrote: > > I guess that the operation is executed in two steps: > > 1st: Create the file with mode 444 (this succeeds, the file is created with > 444) > 2nd: Open the the file with O_WRONLY (fails as it need require write > permission) > > But, as this syscall creates the file and opens the newly created file > aa-same- > time, it should be able to create it with any permission it wants and still be > able to write to it.
It's not a bug in NTFS-3G, it's one in the fuse module which I use on the test machine. Explanation: When I mount with -odebug, I see this: MKNOD /.create444.test NODEID: 3 unique: 52, error: 0 (Success), outsize: 136 unique: 53, opcode: OPEN (14), nodeid: 3, insize: 48 unique: 53, error: -13 (Permission denied), outsize: 16 So this is bound to fail with the way the fuse kernel module does this on this machine. I tested on a different machine with a newer kernel and it issues a CREATE command instead, and the testcase works beautifully... :-) I found out that the sequence MKNOD, OPEN is only a fallback in case CREATE is not available in the usermode the fuse driver, but the kernel module never tried CREATE on that machine, so that fuse module is broken. I'll try to find out why, but it's some issue which I have to find out. Sorry for the wrong report, I'll check how this happened myself, Bernhard ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ ntfs-3g-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ntfs-3g-devel
