Thanks for the tip Sam, I had already been trying to find the problem with both the -d option and my own log file. I also tried the -s option, which in python also can be enabled by setting the multithreaded attribute to 0.
I'll give the relevant output of the -d option. 1) Copy a picture to the xmp.py filesystem. Debug: http://pastie.org/458597 The error I get is the following: The operation cannot be completed because the item "001.jpg" is locked. I'm sure it's not locked in the original filesystem. 2a) As 2a is the operation that's always failing I'll give the output of that one. This is using my own filesystem. Debug: http://pastie.org/458600 I started from an empty directory and database. A readdir() of the root returns 3 results: +ADD, +REMOVE and +FIND. Getattr() returns that these are symbolic links. Readlink() returns that they link to a folder with the same name, but prefixed by a point. So symbolic link / +ADD points to /.+ADD. Note that this /.+ADD folder was not in the readdir() of the root, but that a readdir() and/or getattr() of that path will return the correct information. As the problem also occured when these folders where still returned by readdir() of the root, this isn't the problem. To simulate problem 2a, I made a simple text file and tried save as. I selected my filesystem and opened /+ADD (thus /.+ADD). I then created a folder named "test". The debug output linked below starts from the moment I clicked "new folder" in the save dialog. What happens then is that the save dialog "jumps" away from the filesystem. In the dropdown at the top I only see "test", no parents folders or anything else. I also briefly see the symbolic links +AND and +SAVE (both again pointing to folders with the same name but prefixed with a point) but they disappear. Also mysterious is that when I go again to the filesystem and to /. +ADD, I cannot create a new folder named "test" as it already exists... but I don't see it. I noticed that there are getxattr() requests in the log, but I haven't implemented that. Also, I see getattr() requests for ._foldername files/folders, which is where extended attributes are stored when the functions are not implemented (I think). However, I don't have any code yet that allows the creation of such files/folders (at least not in .+ADD folders). 3) Saving a Word document to the xmp.py filesystem. Debug: http://pastie.org/458602 The mirrored directory is empty. I try to save a word file as Test.doc. This is the output from the moment I clicked save in Word until I got the following (general) message: ---------------------------------------------------------------------- Word cannot save or create this file. The disk may be full or write- protected. Try one or more of the following: * Free more memory. * Make sure that the disk you want to save the file on is not full, write-protected or damaged. (Test.doc) ---------------------------------------------------------------------- Any ideas? On 26 Apr 2009, at 08:50, Sam Moffatt wrote: > > Have you enabled the debug output to see what operations are being > sent where? Erratic behaviour sounds like something is being called > that isn't returning something expected or consistent with what ever > else is being returned. The -d option I think should enable that. You > might also want to see if this is an async problem with -s which > should force it to be synchronised by the kernel (e.g. only get one > request at a time) - though I'm not too sure about if Python would > enforce this by its nature anyway. > > > > Sam Moffatt > http://pasamio.id.au > > > > On Sun, Apr 26, 2009 at 9:27 AM, Karel Marissens > <[email protected]> wrote: >> >> Update: >> >> I just tried the example (mirror) Fuse filesystem. Both the first and >> last problem also occur there (I can't test 2). >> I'm using the python-fuse bindings. >> >> I really hope someone has an idea... >> >> Karel >> >> On 25 Apr 2009, at 17:09, Karel Marissens wrote: >> >>> Hi, >>> >>> I've written a combination of a hierarchical and tag-based >>> filesystem using Fuse. There is the hierarchical part, which is a >>> mirror of a folder on my OS X drive. For each file in the hierarchy, >>> an entry can exist in the database (xapian) which links it with >>> certain tags. This information is usable due to "special folders". >>> In every folder of the hierarchical part of the filesystem in Fuse, >>> the special folders +ADD, +REMOVE and +FIND exist to add/remove tags >>> to/from files and search for files using the tags. These are off- >>> course "virtual", they don't exist in the actual hierarchy. >>> >>> I'm currently experiencing various problems and I have no clue >>> what's going wrong. I've been looking through log files for days and >>> don't find it. >>> >>> These are the problems: >>> >>> 1) Copy external files/folders to the Fuse filesystem often gives >>> errors. >>> >>> When I do this action in terminal, I get "could not copy extended >>> attributes to ....: Operation not permitted" errors for some of the >>> files. I haven't implemented any extended attribute functions. >>> >>> When I do the same action in Finder, I get one of the following >>> errors: >>> - The operation cannot be completed because you do not have >>> sufficient privileges for "file.jpg". >>> - The operation cannot be completed because the item "file.jpg" is >>> locked >>> >>> I can't seem to find any logic in it. I have a folder of 30 images I >>> try to copy. Sometimes copying a file in the Finder works, sometimes >>> not... >>> I get 8 errors in terminal about extended attributes, but this does >>> not match with the amount of files that give errors in the Finder. >>> >>> When I use the novncache option, this problem goes away, but the >>> filesystem itself gets slower. >>> >>> >>> 2) Finder "jumps" to parent folders in certain actions with virtual >>> folders >>> >>> There are actually 2 places I often get this problem: >>> >>> 2a) When adding a tag in a Finder save dialog >>> >>> When I want to save a file, I go to the hierarchical directory of my >>> choice. Then to directly tag files, I can go into the special folder >>> +ADD. This gives me a list of all tags, so I can select one. After >>> selecting one I can go on to add as many tags as I'd like to the >>> file. This works fine. >>> >>> Now if I want to use a new tag while saving a file, I would go into >>> the +ADD special folder and create a folder with the tag name of my >>> choice. That's where it goes wrong. For a moment, I see the folder >>> getting created and the content being displayed (to further select >>> other tags). Then the Finder "jumps" away. That is, the name of the >>> created folder is still visible in the dropdown at the top of the >>> save dialog. The subfolders are gone and when clicking on the >>> dropdown at the top, I no longer see the parent folders,... >>> >>> This ALWAYS happens. >>> At the end of the mkdir() function, I called readdir(parent) and >>> getattr(newfolder) to check if the new folder exists and it does. So >>> it doesn't seem to be that there's some kind of delay between adding >>> the folder (tag) to the database (mkdir) and finding it in the >>> database (readdir and getattr). >>> >>> 2b) When browsing +FIND >>> >>> When you want to search for a file based on tags, you open up the >>> special folder +FIND from the directory of your choice. A folder >>> list of all tags used on any file in the directory of any of its >>> subfolders will be shown. Opening one of these folders (tags) gives >>> you a list of special folders with +FILES, +AND, ... >>> Opening +FILES would give all files matching the "query". >>> Opening +AND would give a list of folders of all tags that can be >>> combined with the previous selected tags. >>> >>> Example: >>> /photos/+FIND --> list of all tags (displayed as folders) for files >>> in /photos or any of its subfolders >>> /photos/+FIND/tag1 --> special folders +FILES, +AND, ... >>> /photos/+FIND/tag1/+AND --> list of all tags (displayed as folders) >>> that can be combined with tag1 >>> /photos/+FIND/tag1/+AND/tag2 --> special folders +FILES, +AND, ... >>> /photos/+FIND/tag1/+AND/tag2/+FILES --> list all files in /photos or >>> any of its subfolders, that are tagged with both tag1 and tag2 >>> >>> In some situations (I haven't really found a certain situation that >>> always triggers this behavior), I see the content of a folder gets >>> displayed very shortly, followed by the Finder "jumping" back to a >>> parent folder. Often, folders then become impossible to open (In >>> column mode in Finder, I just see some details as you would when >>> selecting a file). >>> >>> I'm not entirely sure, but it is possible that the behavior of 2b >>> does not occur when the novncache option is used. 2a however happens >>> all the time. >>> >>> >>> 3) I cannot save a Microsoft Word file directly in the filesystem. >>> >>> I can save files from within preview, textmate, textedit, safari, >>> openoffice, ... >>> I cannot save files from within Microsoft Word, Adobe Photoshop, >>> Audio Recorder (no error here, but the file won't play), ... >>> >>> >>> >>> Any ideas on any of the problems would be great. >>> >>> Thanks in advance, >>> >>> Karel >> >> >>> >> > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
