Hi Alex I'm facing the same problems that you mentioned three posts from here. Can you please share how you got it working?
Ted, I implemented setAttributes like you told me to. Not returning a YES for everything now without checking. There's this particular log statement I get every time createFileAtPath is called unique: 4, opcode: CREATE (35), nodeid: 14, insize: 58 2008-12-05 20:02:35.527 WebServFS[3569:7c03] Create file at path:/ TestFolder/test2/hello.txt unique: 4, error: -13 (Permission denied), outsize: 16 where hello.txt is the file I'm trying to create. The methods I've implemented are createFileAtPath, attributesOfItemAtPath, setAttributes, writeFileAtPath I'm creating the file in createFileAtPath and editing its data in writeFileAtPath. Do I need to do anything else? Thanks for any help! On Dec 2, 11:41 pm, "ted bonkenburg" <[EMAIL PROTECTED]> wrote: > 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 > > ... > > 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 -~----------~----~----~----~------~----~------~--~---
