> It sounds like you've made some progress! > > You keep referencing "/tmp". Is that where you are mounting your file > system? If so, I'd recommend that you mount somewhere else or at least > in a subdirectory of /tmp. The Mac OS X will use /tmp for all sorts of > things (just do an ls -al on /tmp before you mount to see) and it > would be better to let that be and not interfere with debugging your > file system.
Yes, I plan on creating it's own sub directory. /tmp was just what I threw in at the time and I haven't gotten around to changing it yet. > The standard file save process in a standard Cocoa application is more > complicated than you might expect. TextEdit is a good example of this. > I gave a talk on the Objective-C framework at Cocoaheads a while back. > The presentation slides can be found here: > > http://inaddrany.com/macfuse/ > > If you look at slide 10, this describes one code path that TextEdit > may use to save a file. You can see it requires support for mkdir, > create, write, rename, and unlink all to save a file. I suspect chown, > chmod, truncate, and utimes might also be necessary for things to work > smoothly in saving a file. > > A video of the talk is available in case it might help: > > http://theocacao.com/document.page/543 This is exactly what I was looking for! I watched the video weeks ago and must have made a mental note of that slide since I knew I remember seeing something like that somewhere, but I couldn't remember where. > You should get drag-copy working before you try to get file save > working. It sounds like you may not be implementing > setAttributesOfItemAtPath properly. It might be that you need to > support setting of times as well as changing of file permisssions and > ownership. Be sure to return "YES" from setAttributesOfItemAtPath: if > you are able to set the attributes. If you are unable then try to > determine why. Thanks for the tip, I will make this the next bit I work on. > You shouldn't have to do that. You should always get a createFile call > if the file needs to be created. If you are treating writeFile as a > create operation then something is wrong. I create an empty file in the createFile since there are times when only createFile is called and writeFile is never called (like Touch, for example). In writeFile I again use the writeFileAtPath method to then write the file with actual data. Is there a better way to do this? Thanks for the quick response! -Alex On Dec 2, 12:29 pm, "ted bonkenburg" <[EMAIL PROTECTED]> wrote: > On Tue, Dec 2, 2008 at 8:45 AM, Alex <[EMAIL PROTECTED]> wrote: > > > It's been awhile, but I'm still strugling to get the writing done > > correctly. Here is where I stand now: > > > I've gotten all of the commands you listed above to work from the > > command line. So now I've moved on to tackling Finder problems. > > Creating a new file in vi and saving it to the mount works as > > expected. A new file is created in /tmp and is uploaded to the > > server. > > It sounds like you've made some progress! > > You keep referencing "/tmp". Is that where you are mounting your file > system? If so, I'd recommend that you mount somewhere else or at least > in a subdirectory of /tmp. The Mac OS X will use /tmp for all sorts of > things (just do an ls -al on /tmp before you mount to see) and it > would be better to let that be and not interfere with debugging your > file system. > > > > > Creating a new file with TextEdit however fails. After saving to the > > mount I get the following dialog message: > > "The document "Unititled" could not be saved as "test.rtf". ". The > > file does get saved to /tmp and is uploaded to the server. I can't > > figure out why this message is popping up. I have debugging enabled > > and I have a lot of debugging text, but I can't pinpoint exactly where > > the problem is. > > The standard file save process in a standard Cocoa application is more > complicated than you might expect. TextEdit is a good example of this. > I gave a talk on the Objective-C framework at Cocoaheads a while back. > The presentation slides can be found here: > > http://inaddrany.com/macfuse/ > > If you look at slide 10, this describes one code path that TextEdit > may use to save a file. You can see it requires support for mkdir, > create, write, rename, and unlink all to save a file. I suspect chown, > chmod, truncate, and utimes might also be necessary for things to work > smoothly in saving a file. > > A video of the talk is available in case it might help: > > http://theocacao.com/document.page/543 > > > > > Creating a new file with TextMate works as well. > > Some apps have a much simpler version of "Save". > > > > > Opening files from within the mount then trying to save them back does > > not work either.. but I'm figuring this is a seprate issue and that I > > should get creating new files working correctly first. > > > Copying (by dragging) a new file over to the mount gives me several > > errors. First I get a warning message telling me I may need to enter > > a password to change the file. After hitting continue I get another > > box informing me that the file has one or more items I do not have > > permission to read. Clicking continue again, I'm finally warned that > > the operation could not be completed because the file already exists. > > The file is created in both /tmp and on the server but is never > > written to. > > You should get drag-copy working before you try to get file save > working. It sounds like you may not be implementing > setAttributesOfItemAtPath properly. It might be that you need to > support setting of times as well as changing of file permisssions and > ownership. Be sure to return "YES" from setAttributesOfItemAtPath: if > you are able to set the attributes. If you are unable then try to > determine why. > > > > > I should mention that I create the file both in the createFile and > > writeFile methods. > > You shouldn't have to do that. You should always get a createFile call > if the file needs to be created. If you are treating writeFile as a > create operation then something is wrong. > > ted > > > > > Any guidence on these issues would be appreciated. > > > Thank you, > > -Alex > > > On Nov 5, 1:33 pm, "ted bonkenburg" <[EMAIL PROTECTED]> wrote: > >> On Tue, Nov 4, 2008 at 6:48 AM, Alex <[EMAIL PROTECTED]> wrote: > > >> > As on update: > > >> > I had already refrenced LoopbackFS heavily, but to be sure I ended up > >> > copying the entire file and making changes from there. Creating a new > >> > file now works from the command line and persists the data correctly > >> > back to the server. However I can't seem to get modifying data on the > >> > server to work correctly. > > >> > From the command line I open a file on the filesystem using Vi. The > >> > file contents are correctly displayed. The log shows that > >> > a /.file.txt.swp is created. I then edit the file and save back the > >> > changes. I get a warning telling me that the file has changed since > >> > reading it. I choose to write anyway and the the program goes into an > >> > infinite loop. The log file shows that its continualy getting the > >> > attributes of increasing numbered files, such as /4913, /5036, ect. > > >> > If I try echoing text into a file already on the filesystem I get a > >> > permission denied message. > > >> You should focus on fixing the latter issue first. Get these > >> fundamental things working before you even try using vi: > > >> touch /Volumes/myfs/foo.txt > >> echo "blah" > /Volumes/myfs/foo.txt > >> chmod 777 /Volumes/myfs/foo.txt > >> echo -n > /Volumes/myfs/foo.txt > >> cp /tmp/bar /Volumes/myfs/foo.txt > > >> If echo'ing text into a file system like "echo "blah" > > >> /Volumes/myfs/foo.txt" is failing, then: > > >> 1) Do you implement truncate and support it properly? > >> 2) Are you returning proper write permissions in attributesOfItem: for > >> that file? > >> 3) Are you implementing openFileAtPath: properly? > >> 4) Are you implementing writeFileAtPath: properly? > > >> Have you tried adding the "debug" option at mount time? You can use > >> Console.app to view log messages or if you are running in xcode you > >> can show the Console there while your FS is "running". Look for failed > >> operations in the debug output. Somehow your file system is returning > >> EPERM. This is returned by default in some cases within > >> GMUserFileSystem if a delegate method is not implemented, so it could > >> be related to that as well. > > >> ted > > >> > Any ideas? > > >> > On Oct 30, 4:37 pm, "ted bonkenburg" <[EMAIL PROTECTED]> wrote: > >> >> On Thu, Oct 30, 2008 at 2:17 PM, Alex <[EMAIL PROTECTED]> wrote: > > >> >> > Thanks for the quick reply Ted. Sorry about the ambiguous post, it > >> >> > kind of feels like I'm coding in the dark a little bit. > > >> >> > Here are a few more specifics: > >> >> > 1. Mac OS X version: 10.5.5 > >> >> > 2. arch (x86, ppc, x86_64, ppc64): x86 > >> >> > 3. MacFUSE version: Latest (1.7) > > >> >> > I have implemented most of the delegate methods, except for the > >> >> > extended attributes ones, mostly just to see if they were being > >> >> > called. I don't set the fileDelegate in the createfile function, and > >> >> > openfile is never called. > > >> >> > I tried using the command line operations and am getting the same > >> >> > output in the log. I haven't messed around with it too much yet, I > >> >> > will continue working on it tomorrow, I just wanted to get this > >> >> > posted. Here is a list of delegates that I have implemented (and at > >> >> > least compiling without errors). > > >> >> Thanks for the quick update. Compiling without errors is a start, but > >> >> of course you'll need to have a proper implementation that returns the > >> >> right error codes when appropriate, etc. It is not easy to help with > >> >> something like this via email, so I'll let you spend a bit more time > >> >> on it tomorrow before I hazard any guesses. > > >> >> You might want to look at the LoopbackFS file system. That has full > >> >> write support, so at least you can see that it should work and maybe > >> >> get an idea what it is doing. > > >> >> See LoopbackFS.m here: > > >> >>http://macfuse.googlecode.com/svn/trunk/filesystems-objc/LoopbackFS/ > > >> >> ted > > >> >> > attributesOfFileSystemForPath > >> >> > attributesOfItemAtPath > >> >> > contentsOfDirectoryAtPath > >> >> > setAttributes > >> >> > contentsAtPath > >> >> > createDirectoryAtPath > >> >> > createSymbolicLinkAtPath > >> >> > linkPath > >> >> > createFileAtPath > >> >> > writeFileAtPath > >> >> > truncateFileAtPath > >> >> > movePath > >> >> > removeFileAtPath > >> >> > openFileAtPath > >> >> > readFileAtPath > >> >> > exchangeDataOfItemAtPath > >> >> > moveItemAtPath > >> >> > removeDirectoryAtPath > >> >> > removeItemAtPath > > >> >> > Thanks for the help. > > >> >> > -Alex > > >> >> > On Oct 30, 4:42 pm, "ted bonkenburg" <[EMAIL PROTECTED]> wrote: > >> >> >> See comments inline. Also, in the future, it might be useful to > >> >> >> indicate: > > >> >> >> 1. Mac OS X version > >> >> >> 2. arch (x86, ppc, x86_64, ppc64) > >> >> >> 3. MacFUSE version > > >> >> >> On Thu, Oct 30, 2008 at 12:58 PM, Alex <[EMAIL PROTECTED]> wrote: > > >> >> >> > I've been having a lot of trouble creating a writable filesystem > >> >> >> > using > >> >> >> > the objective-c framework. The filesystem is remote, the contents > >> >> >> > are > >> >> >> > stored on a website. I have gotten reading to work fine, but > >> >> >> > getting > >> >> >> > files to be written back has not been working, and I'm not entirely > >> >> >> > sure where to go from here. I'm not sure if I'm not implementing a > >> >> >> > function I need to be, or if I'm implementing one of the core > >> >> >> > functions incorrectly. > > >> >> >> That is most likely the explanation. I'm being vague on purpose here > >> >> >> because it is not easy to tell what the problem is without seeing the > >> >> >> code. > > >> >> >> If you are doing a read-only file system you can often get away with > >> >> >> leaving out implementations of some of the delegate methods; the > >> >> >> GMUserFileSystem code will try to do something reasonable to fill in > >> >> >> for you. > > >> >> >> When adding write support, you typically need to implement almost all > >> >> >> of the delegate methods and have them return proper error codes, etc. > >> >> >> Write support is almost all-or-nothing and not very forgiving, > >> >> >> especially when it comes to operations done through the Finder. > > >> >> >> > What I want to be able to do is write that file over the server > > ... > > read more » --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
