I would suggest that you should do your best to honour what the operating system wishes to do with your FS. Those files are being created due to missing extended attribute support IIRC (appears to be true in your case as I note a op not supported just prior) and are created to ensure that items that HFS would normally handle transparently aren't lost. I believe that this is actually part of the kernel layer that transparently provides extended attribute/fork support regardless of the actual underlying filesystem - they aren't created by Finder. Someone like Ted or Amit will be able to correctly on the details of this on the areas I'm wrong, but this is what I believe the case to be.
If you _really_ didn't want to handle those files I'd either 1) handle the xattr commands perhaps with an in memory temporary store (so that if the system validates that the data got to the other end it doesn't bail out due to that) or 2) handle writing the files but put them into some in-memory cache if you don't want to retain one of these (for the same reason as xattr). Ideally you would handle this properly, but it would appear you don't want to do that however you should at least make your FS try to behave properly even if it isn't really doing that underneath otherwise you'll see almost pathological behaviour from operating systems. Sam Moffatt http://pasamio.id.au On Thu, Dec 11, 2008 at 8:16 PM, iDeveloper <[EMAIL PROTECTED]> wrote: > Hi > I am trying to make a read-write file system and using a MacFUSE 2.0 > template as the base. When I write to a file, the FS keeps looking for a > ._<my file> > Is this file necessary for writing to a file? I am not handling temporary > files created by the Finder. Are they required for write operation to work? > These are the logs I get when I save a file edited in TextEdit. It keeps > looking for folders named A Document Being Saved By TextEdit till A Document > Being Saved By TextEdit 1000 > and then finally gives an alert stating the file could not be saved. > Anything I missed? > unique: 1, opcode: GETATTR (3), nodeid: 29, insize: 40 > unique: 1, error: 0 (Unknown error: 0), outsize: 128 > unique: 3, opcode: GETXATTR (22), nodeid: 29, insize: 77 > unique: 3, error: -45 (Operation not supported), outsize: 16 > unique: 0, opcode: LOOKUP (1), nodeid: 25, insize: 57 > LOOKUP /FileSystem(KUROBOX-PRO)/test2/._gotThisOld.txt > NODEID: 30 > unique: 0, error: 0 (Unknown error: 0), outsize: 152 > unique: 4, opcode: OPEN (14), nodeid: 30, insize: 48 > unique: 4, error: -2 (No such file or directory), outsize: 16 > unique: 2, opcode: GETATTR (3), nodeid: 29, insize: 40 > unique: 2, error: 0 (Unknown error: 0), outsize: 128 > unique: 1, opcode: GETXATTR (22), nodeid: 29, insize: 77 > unique: 1, error: -45 (Operation not supported), outsize: 16 > unique: 3, opcode: LOOKUP (1), nodeid: 25, insize: 57 > LOOKUP /FileSystem(KUROBOX-PRO)/test2/._gotThisOld.txt > NODEID: 30 > unique: 3, error: 0 (Unknown error: 0), outsize: 152 > unique: 0, opcode: OPEN (14), nodeid: 30, insize: 48 > unique: 0, error: -2 (No such file or directory), outsize: 16 > unique: 4, opcode: GETATTR (3), nodeid: 1, insize: 40 > unique: 4, error: 0 (Unknown error: 0), outsize: 128 > unique: 2, opcode: GETATTR (3), nodeid: 17, insize: 40 > unique: 2, error: 0 (Unknown error: 0), outsize: 128 > unique: 1, opcode: GETATTR (3), nodeid: 25, insize: 40 > unique: 1, error: 0 (Unknown error: 0), outsize: 128 > unique: 3, opcode: GETXATTR (22), nodeid: 29, insize: 77 > unique: 3, error: -45 (Operation not supported), outsize: 16 > unique: 0, opcode: LOOKUP (1), nodeid: 25, insize: 57 > LOOKUP /FileSystem(KUROBOX-PRO)/test2/._gotThisOld.txt > NODEID: 30 > unique: 0, error: 0 (Unknown error: 0), outsize: 152 > unique: 4, opcode: OPEN (14), nodeid: 30, insize: 48 > unique: 4, error: -2 (No such file or directory), outsize: 16 > unique: 2, opcode: GETXATTR (22), nodeid: 29, insize: 79 > unique: 2, error: -45 (Operation not supported), outsize: 16 > unique: 1, opcode: LOOKUP (1), nodeid: 25, insize: 57 > LOOKUP /FileSystem(KUROBOX-PRO)/test2/._gotThisOld.txt > NODEID: 30 > unique: 1, error: 0 (Unknown error: 0), outsize: 152 > unique: 3, opcode: OPEN (14), nodeid: 30, insize: 48 > unique: 3, error: -2 (No such file or directory), outsize: 16 > unique: 0, opcode: GETATTR (3), nodeid: 6, insize: 40 > unique: 0, error: 0 (Unknown error: 0), outsize: 128 > unique: 4, opcode: GETXATTR (22), nodeid: 6, insize: 77 > unique: 4, error: -45 (Operation not supported), outsize: 16 > unique: 2, opcode: LOOKUP (1), nodeid: 1, insize: 51 > LOOKUP /._.Trashes > NODEID: 7 > unique: 2, error: 0 (Unknown error: 0), outsize: 152 > unique: 1, opcode: OPEN (14), nodeid: 7, insize: 48 > unique: 1, error: -2 (No such file or directory), outsize: 16 > unique: 3, opcode: LOOKUP (1), nodeid: 1, insize: 56 > LOOKUP /.TemporaryItems > NODEID: 39 > unique: 3, error: 0 (Unknown error: 0), outsize: 152 > unique: 0, opcode: GETXATTR (22), nodeid: 39, insize: 77 > unique: 0, error: -45 (Operation not supported), outsize: 16 > unique: 4, opcode: LOOKUP (1), nodeid: 1, insize: 58 > LOOKUP /._.TemporaryItems > NODEID: 40 > unique: 4, error: 0 (Unknown error: 0), outsize: 152 > unique: 2, opcode: OPEN (14), nodeid: 40, insize: 48 > unique: 2, error: -2 (No such file or directory), outsize: 16 > unique: 1, opcode: LOOKUP (1), nodeid: 25, insize: 77 > LOOKUP /FileSystem(KUROBOX-PRO)/test2/(A Document Being Saved By TextEdit) > NODEID: 41 > unique: 1, error: 0 (Unknown error: 0), outsize: 152 > unique: 3, opcode: LOOKUP (1), nodeid: 25, insize: 79 > LOOKUP /FileSystem(KUROBOX-PRO)/test2/(A Document Being Saved By TextEdit 2) > NODEID: 42 > unique: 3, error: 0 (Unknown error: 0), outsize: 152 > unique: 0, opcode: LOOKUP (1), nodeid: 25, insize: 79 > LOOKUP /FileSystem(KUROBOX-PRO)/test2/(A Document Being Saved By TextEdit 3) > NODEID: 43 > unique: 0, error: 0 (Unknown error: 0), outsize: 152 > unique: 4, opcode: LOOKUP (1), nodeid: 25, insize: 79 > LOOKUP /FileSystem(KUROBOX-PRO)/test2/(A Document Being Saved By TextEdit 4) > NODEID: 44 > unique: 4, error: 0 (Unknown error: 0), outsize: 152 > > > On 10-Dec-08, at 10:17 PM, ted bonkenburg wrote: > > On Wed, Dec 10, 2008 at 6:13 AM, iDeveloper <[EMAIL PROTECTED]> wrote: > > Hi > > I am very close to implementing write (finally!!). Just one thing > > stopping me. > > When I do a save operation, I get this message in the writeToFile > > method > > *** -[GMDataBackedFileDelegate longValue]: unrecognized selector sent > > to instance 0x16cb30f0 > > I am using an implementation similar to the one in LoopbackFS and > > assigning an NSNumber to the fileDelegate property when a file is > > created. > > I understand that this would happen if the value for fileDelegate was > > not retained. Or is there some other problem? > > Is there any chance that you'd switch to targeting MacFUSE 2.0+? I'm > not saying that it would solve this particular issue, but it would > make it easier for me to try and help you debug. > > The GMDataBackedFileDelegate is a class that is internal to the > framework. I added that to solve someone else's problem; I can't even > recall what it was. I think this is only used if you are using the > contentsAtPath: method on the read side. If you are doing a writeable > file system then you should not be using the "contentsAtPath:" > shortcut. You should be implementing openFileAtPath: and > readFileAtPath:. > > The new project templates in MacFUSE 2.0 might help you a bit; try > using the Objective-C File System (Read-Write) template. Be careful > not to accidentally overwrite your old project by naming it the same > thing! > > ted > > > Thanks. > > On Dec 6, 3:52 am, "ted bonkenburg" <[EMAIL PROTECTED]> wrote: > > On Fri, Dec 5, 2008 at 8:52 AM, iDeveloper <[EMAIL PROTECTED]> wrote: > > Hi Ted > > I implemented setAttributes like you told me to. Not returning a YES > > for everything now without checking. > > I'm not sure what you mean by checking. You should be setting the > > requested attributes on the files in your file system. > > > > I still cannot save files edited using vi or TextEdit. > > But if I drag-drop files, the file is getting created at the server to > > which I can later append the data. How can I get the contents of the > > file which was dragged into the FS? > > When you copy a file into your file system you should see a create > > operation followed by a series of writes. > > The "Save As" procedure for a file within your file system can be > > somewhat complicated. See: > > Seehttp://groups.google.com/group/macfuse/msg/46c6c4012ec339c3 > > ted > > > > Thanks again for all your help. > > On Dec 3, 8:25 pm, iDeveloper <[EMAIL PROTECTED]> wrote: > > Hi Ted > > I still don't really get it. Do I check what attributes are coming in > > as arguments and change them before returning a value? > > I'm using version 1.7 > > On Dec 2, 3:33 am, "ted bonkenburg" <[EMAIL PROTECTED]> wrote: > > On Mon, Dec 1, 2008 at 8:00 AM, iDeveloper <[EMAIL PROTECTED]> wrote: > > Hi Ted > > I got the read to work along with copying files from the FS to the > > local file system, both through Finder and the command line. > > Great. > > I have implemented the setAttributes:ofItemAtPath method, but I > > noticed it is only called once or twice and that too for files created > > by finder. > > Yes, this won't be called that often. It is called when something is > > updating an attribute of your file, for example 'chmod', 'chown', > > 'utimes', etc. If you are using the developer release of MacFUSE then > > you will see that it is also called when the file is 'truncated'. > > What should I have in setAttributes? Aren't we setting the attributes > > for files in attributesOfItemAtPath. At present I'm just returning a > > YES in setAttributes > > Think of it this way. In attributesOfItemAtPath you are reporting on > > the attributes of a file or directory. This is a "read" operation. The > > system is reading what the current attributes for the file are. With > > setAttributes you are setting the attirbutes of a file or directory in > > your file system. This is a "write" operation. The system is setting > > something about your file, and so your file system needs to update the > > file accordingly. > > Returning YES without doing anything else is claiming that you are > > updating the file when you actually aren't. It is recommended that you > > actually see what attributes are being set and update your files as > > necessary. In some cases it does work to satisfy the Finder to just > > return YES, but this can lead to strange issues down the road that are > > hard to debug. Think of it as 'chmod' claiming success but not > > actually chmod'ing the file. > > What should be my next step for implementing thewritefunction? > > It would be a good idea to implement setAttributes fully, as described > above. > > What version of MacFUSE are you targeting? > > ted > > > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "MacFUSE" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/macfuse?hl=en -~----------~----~----~----~------~----~------~--~---
