On Tue, Dec 2, 2008 at 10:23 AM, Alex <[EMAIL PROTECTED]> wrote: > >> 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?
It sounds like what you are doing is correct. The writeFileAtPath shouldn't be creating a file in your file system; it should just be writing/appending data at the given offset. ted > > 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 -~----------~----~----~----~------~----~------~--~---
