raincity1026 / openmeta Goto Github PK

got some feedback - which is right - the NSErrors should not be returned. They 
should be in the 
arg list. Will change for the next checkin, again changing the API. So keep the 
number of places you 
call OpenMeta as small as possible! --Tom

What steps will reproduce the problem?
1. touch test
2. openmeta -s "multiword, mit komma und blank" -p ./test

What is the expected output? 
"multiword, mit komma und blank" ./test

What do you see instead?
multiword " mit komma und blank" ./test

What version of the product are you using? On what operating system?
version 0.1 on Mac OS

Please provide any additional information below.

Tagging software like Yep2 allow commas in tags. In fact, openmeta command line 
will read tags with commas. But it will not allow one to set tags with commas. 
There is no reason that a tag, in quotes, with commas should not be allowed

What steps will reproduce the problem?
1. Try to run openmeta on several files with spaces in the path.
2. Single quote every file... and watch out if it already has a single quote.
3.

What is the expected output? What do you see instead?
find / -print0 | openmeta -a tag -0 # tag all files...

What version of the product are you using? On what operating system?
SVN as of yesterday.

Please provide any additional information below.

Makes it difficult to enable folder actions, use tools like Hazel, or otherwise 
script things to happen 
on "tag change". Tag time is recorded, and can be used to diff with a "last 
checked" time, but there 
seems to be no filesystem event fired on tag change. 

I would like to see someone add a Homebrew (http://mxcl.github.io/homebrew/) 
formula for openmeta that will build the commandline tool as well as the 
spotlight plugin.

So I submit an app to the app store using OpenMeta, and it is rejected because 
it writes to Library/Application\ Support/OpenMeta/ when applications are only 
meant to write to a folder according to their app name.

OK, so we all know the AppStore rules are crap, etc, but this is the world we 
live in now, so what is the solution? My initial thought is that OpenMeta 
writes its backups to the appname folder, as I understand it they are just 
backups, and then if anything needs to restore these backups, well something 
has to search ALL the app folders to find it. A bit crappy in some ways, but I 
don't see another option.

Why hasn't anyone else come across this problem?

Version 3.0 of the OpenMetaSpotlight.mdimporter implements the change from 
kOMUserTags to 
kMDItemOMUserTags in the schema.strings file. This breaks Smart Folders that 
search for tags 
and which were created using earlier versions of the mdimporter. These older 
Smart Folders use 
the kOMUserTags key in their .savedsearch files, and thus fail to work with v. 
3.0 of the 
mdimporter, which specifies kMDItemOMUserTags instead.

In specific, versions of the mdimporter prior to v. 3.0 included the following 
in schema.strings:

"kOMUserTags" = "Tags";

As a result, Smart Folders made with "Tags" criteria would include the 
following in their 
FXCriteriaSlices key of their SearchCriteria key:

<array>
    <dict>
        <key>criteria</key>
        <array>
            <string>kOMUserTags</string>
            <integer>120</integer>
            <integer>104</integer>
        </array>
        <key>displayValues</key>
        <array>
            <string>Tags</string>
            <string>matches</string>
            <string>foo</string>
        </array>
        <key>rowType</key>
        <integer>0</integer>
        <key>subrows</key>
        <array/>
    </dict>
</array>

By changing the schema.strings values to read:

"kMDItemOMUserTags" = "Tags";

version 3.0 of the mdimporter causes all of these Smart Folders to die a 
horrible death, complete 
with graphical glitches in the Finder window if the user tries to manually edit 
the search criteria 
of the broken Smart Folder.

While I appreciate the need to address the problem with Snow Leopard 
overwriting extended 
attributes, introducing a change that renders a user's previously saved 
searches inoperable—and 
thereby renders my software, Tag Folders, inoperable—is not acceptable. 

Moreover, even if I were to implement a method to rewrite all of the Smart 
Folders created by my 
software (and leave the user to fend for themselves with their own broken Smart 
Folders), I 
would not be able to avoid problems. Because there are multiple, incompatible 
versions of the 
mdimporter floating around inside various application bundles that the user may 
have installed, 
and only one of them will be used by Spotlight at a time, it is not an easy 
task to determine 
whether a user's system currently thinks that "Tags" in the Spotlight search 
criteria means 
kOMUserTags or kMDItemOMUserTags. This means that I can't reliably choose one 
or the other 
key.

Something must be done to address this, not only for my software to keep 
working, but so that 
users don't suddenly find that their Smart Folders are horribly broken.

What steps will reproduce the problem?
1. download the V1.3 commandline utility
2. try and list openmeta tags with -p
3.

What is the expected output? What do you see instead?
I should see my tags, instead I see this:

═◎ openmeta -p Screen\ Shot\ 2013-10-18\ at\ 01.04.29.png 
Screen Shot 2013-10-18 at 01.04.29.png
2013-10-18 10:34:25.403 openmeta[7977:507] *** Terminating app due to uncaught 
exception 'NSInvalidArgumentException', reason: '*** -[NSFileManager 
fileSystemRepresentationWithPath:]: nil or empty path argument'
*** Call stack at first throw:
(
    0   CoreFoundation                      0x933266b1 __raiseError + 193
    1   libobjc.A.dylib                     0x9c18d091 objc_exception_throw + 162
    2   CoreFoundation                      0x933265cb +[NSException raise:format:] + 139
    3   Foundation                          0x975dbbbc -[NSFileManager fileSystemRepresentationWithPath:] + 122
    4   Foundation                          0x975dbb31 -[NSString(NSPathUtilities) fileSystemRepresentation] + 62
    5   openmeta                            0x0000af71 +[OpenMetaBackup hashString:] + 29
    6   openmeta                            0x000075b7 +[OpenMetaBackup calculateBackupFileName:] + 127
    7   openmeta                            0x0000970e +[OpenMetaBackup restoreMetadataSearchForFile:withDelay:] + 52
    8   openmeta                            0x00007944 +[OpenMetaBackup restoreMetadata:] + 49
    9   openmeta                            0x00004250 +[OpenMeta getUserTags:error:] + 59
    10  openmeta                            0x00002e02 TagsAsString + 62
    11  openmeta                            0x000037ba main + 2089
    12  openmeta                            0x000029f2 start + 54
    13  ???                                 0x00000003 0x0 + 3
)
[1]    7977 trace trap  openmeta -p Screen\ Shot\ 2013-10-18\ at\ 01.04.29.png

What version of the product are you using? On what operating system?
openmeta V1.3 (though the commandline says openmeta version 0.1) and Mavericks 
GM, tried on a MBP and a MP

Please provide any additional information below.

What steps will reproduce the problem?

1. openmeta -q -s tag names -p ./file


What is the expected output? What do you see instead?

It would be nice if no confirmation output was return by openmeta with a -q 
option is used

What version of the product are you using? On what operating system?

openmeta 1.3
mac 10.6

Please provide any additional information below.

This is helpful when incorporating openmeta is scripts and being in control of 
what is printed to screen

What steps will reproduce the problem?
1. Make sure the current installed version of the importer is < 3.0 (mdimport 
-L)
2. Tag some files "openmeta"
3  Install version 3.0 of the mdimporter (as provided in Default Folder X 2.3.3 
for instance)
4. Make sure Spotlight uses version 3.0 (see above)
5. Tag another (previously untagged file) "openmeta"
6. Perform a Spotlight search on "tag:openmeta"

What is the expected output? What do you see instead?
Expected: all files tagged "openmeta" appear in Spotlight results
Actual: only the file tagged after installing version 3.0 of the importer 
appears in the results.

Hat version of the product are you using? On what operating system?
OpenMetaSpotlight.mdimporter 3.0 on OS X 10.5.8

What steps will reproduce the problem?
In the Spotlight menu and Finder search box, tag searches are done using the 
"tag:" prefix. But in 
the Smart Folder criteria list, the attribute is described as "Tags".

What is the expected output? What do you see instead?
I would expect both situations to use the singular "tag", rather than one in 
the singular and one in 
the plural. 

What version of the product are you using? On what operating system?
OpenMetaSpotlight.mdimporter v. 1.0

What steps will reproduce the problem?

• Run openmeta command without options

What is the expected output? What do you see instead?

• Expect to see a version# in output corresponding to what's in the release 
notes instead of "version 
0.1"

What version of the product are you using? On what operating system?

• 1.2.0 (from openmeta_commandline_1.2.0.zip archive) on 10.5.7

I ran my app (which is using SVN rev.28 of OpenMeta) through the LLVM Clang 
Static Analyzer and 
it reports that stringToSendNS (allocated on line 126) is leaked with a retain 
count of +1 after line 
137 in OpenMetaAuthenticate.m.

I suggest adopting this tool in the development of the OpenMeta library -- it's 
really quite useful.

http://clang-analyzer.llvm.org/

What steps will reproduce the problem?

The current repository layout is trunk/openmeta/trunk/...

What is the expected output? What do you see instead?

The repository layout should have everything in just trunk/...

What version of the product are you using? On what operating system?

svn rev 5

Please provide any additional information below.

N/A

What steps will reproduce the problem?
1. Tag some files "openmeta"
2. Install Default Folder X 2.3.3 (or any other application using the 3.0 
mdimporter)
3. Tag a previously untagged files"openmeta" through app using 3.0
4. run a Spotlight search on "tag:openmeta"

What is the expected output? What do you see instead?
Expected: find all files tagged openmeta
Actual: get only the file tagged with the app using 3.0

What version of the product are you using? On what operating system?
OpenMetaSpotlight.mdimporter 3.0 via Default Folder X 2.3.3 on OS X 10.5.8

Please provide any additional information below.
Only the last tagged file also has a kMDItemOMuserTags attribute, which gets 
picked up; the 
kOMuserTags attributes of previously tagged files are silently ignored.

What steps will reproduce the problem?
1. Run omtool -p foo.txt > ~/Desktop/stdout.txt 2> ~/Desktop/stderr.txt. 

What is the expected output? What do you see instead?
omtool -p foo.txt > ~/Desktop/stdout.txt 2> ~/Desktop/stderr.txt should send 
the results of the 
query to stdout.txt, but instead they are set to stderr.txt

What version of the product are you using? On what operating system?
omtool 0.1 on OSX 10.5.6

Please provide any additional information below.
This makes using omtool in scripts very difficult.

I'm using OpenMeta class (in OpenMeta.h/m) and call +[OpenMeta 
getUserTags:errorCode:] to get 
tags attached to file.
Then, if the file isn't tagged, the method is expected to return error code as 
return value, but 
actually it cause SIGBUS.
I think it isn't right behavior...
( Once tagged and after untagged file is treated rightly.)

To test out omtool, first I ran 
/Users/jon/Downloads/omtool/omtool -a foo bar -p 
/Users/jon/Downloads/omtool/ReadMe.txt
which worked as expected. When I did an mdls on ReadMe.txt, the tags where 
listed in 
kOMUserTags. I made a new Smart Folder in Finder and told it to search for 
"Tags matches foo", 
and it worked perfectly. Later, I decided to test the ratings feature, so I ran
/Users/jon/Downloads/omtool/omtool -r 3.5 -p 
/Users/jon/Downloads/omtool/ReadMe.txt
which successfully applied the rating using kOMStarRating. But when I tried to 
make a Smart 
Folder, Finder wouldn't work properly!

In specific, if I create a new Smart Folder using the File menu in Finder, the 
Smart Folder will 
appear and the first line (the one that defines the scope of the search) will 
be present. But when I 
click the plus button to add specific search criteria, the newly added line is 
blank. It doesn't say 
"Kind is Any", it just has nothing. (See attached screenshot)

If I press ⌘F in a regular Finder window, that particular window will freeze 
up (it won't even 
respond to Expose).

Searches from the Spotlight menu can find data based on criteria that existed 
before I started 
playing with omtool, but it will not find any results if I search for anything 
applied by omtool. For 
example, comments:foo works, but tags:foo doesn't anymore. (Note that tags:foo 
did before I 
used omtool to apply a rating)

This is with omtools 0.1.

My first guess was that omtool had created a new mdimporter in order to allow 
Spotlight to 
index this metadata, and that it was malformed. But I can't find anything that 
looks like it is 
related to Open Meta.

My primary concern is to get my system working properly again, so if you could 
tell me right 
away how I can undo whatever omtool did, I would really appreciate it!

BUMP
What steps will reproduce the problem?

./openmeta 


What is the expected output? What do you see instead?

EXPECTED OUTPUT: openmeta version 2 by Tom Andersen code.google.com/p/openmeta/

OUTPUT:openmeta version 2.0 Nov 11 2013
by Tom Andersen code.google.com/p/openmeta/


What version of the product are you using? On what operating system?

OS X 10.9 Mavericks

Please provide any additional information below.

This is similar to Issues 12 and 15 which obviously weren't addressed either.

What steps will reproduce the problem?
1. cd desktop
2. touch a.txt
3. /path/to/openmeta -s test -p a.txt

What is the expected output? What do you see instead?
Expected:
test a.txt

Actual:
test a.txt
2009-07-10 13:56:46.770 openmeta[8856:1403] *** Terminating app due to uncaught 
exception 'NSInvalidArgumentException', reason: '*** -[NSFileManager 
fileSystemRepresentationWithPath:]: nil or empty path argument'
2009-07-10 13:56:46.771 openmeta[8856:1403] Stack: (
    2427633835,
    2526977595,
    2427633291,
    2427633354,
    2446635124,
    2446634750,
    31666,
    24063,
    23361,
    30194,
    21374,
    2446858398,
    2427136709,
    2427137144,
    2446857189,
    21949,
    2446642701,
    2446641588,
    2513965397,
    2513965074
)
Trace/BPT trap

What version of the product are you using? On what operating system?
openmeta cli tool, version 1.2.0

Please provide any additional information below.
So, the operation succeeds, but clearly something is unhappy. If the full path 
is provided, there is 
no error.

/path/to/openmeta -s test -p a.txt 2>/dev/null produces:
test a.txt
Trace/BPT trap

What steps will reproduce the problem?
1. Assign a tag using omtool -a <TAG> -p <PATH>
2. Try to list the tags using omtool -t -p <PATH>

I expected to see the tags on the file listed, but instead was only given the 
path. Running omtool 
-p <PATH> works as expected, and shows the tags attached to the file, so I know 
they are there.

Here's the terminal session (note, I've put omtool into my $PATH):

stovell-imac:~ jon$ omtool -a tagtest -p /Users/jon/Downloads/omtool/ReadMe.txt 

tagtest /Users/jon/Downloads/omtool/ReadMe.txt
stovell-imac:~ jon$ omtool -t -p /Users/jon/Downloads/omtool/ReadMe.txt
 /Users/jon/Downloads/omtool/ReadMe.txt
stovell-imac:~ jon$ omtool -p /Users/jon/Downloads/omtool/ReadMe.txt
/Users/jon/Downloads/omtool/ReadMe.txt
tags: tagtest
rating: 3.000000

What steps will reproduce the problem?
1. type openmeta
2. read examples

What is the expected output? A way to remove individual tags
What do you see instead? A way to remove all tags
What version of the product are you using? 0.1
On what operating system? MacOSX 10.5

The help file states that commas should not be used, but they appear to work 
fine to separate tags in a string. Instead it only mentions the use of quotes, 
which does not appear possible when setting multiple tags with a script.


What steps will reproduce the problem?

Say I want want to copy multipal tags with spaces with a bash script all at 
once, because this is faster than doing it one at a time, one might have 
expected this to work:

$ tagnames="Cambridge \"New York\"'
$ openmeta -a $tagnames -p ./picture.jpg


What is the expected output? What do you see instead?

openmeta could have interpreted this as two tag names, one as Cambridge and one 
as New York. Instead it sees tags as:
1) Cambridge
2) "New
3) York"

However, if I set the tags with commas like this it works fine:
$ tagnames="Cambridge,New York"
$ openmeta -a "$tagnames" -p ./picture.jpg

The output is: Cambridge "New York"

Why is this apparently not allowed according to the help text, which is printed 
when running openmeta without any inputs? Use of commas like this is very 
useful, particularly because they are used as delimiters in the the output of 
exiftool.

The output of openmeta tags are very difficult to process if there are spaces 
in tag names.


What version of the product are you using? On what operating system?
Version: 1.3 (not 0.1 as stated in help text)
Mac: 10.6

Please provide any additional information below.

I describe what I am using openmeta for and provide my script here: 
http://theadventuresofsuperdoc.blogspot.co.uk/2012/04/how-to-make-picasa-name-ta
gs-be-indexed.html

What steps will reproduce the problem?
1. svn checkout http://openmeta.googlecode.com/svn/trunk/ openmeta-read-only
2. open ./trunk/openmeta/openmeta.xcodeproj in Xcode
3. Attempt to build

What is the expected output? What do you see instead?
Expect openmeta tool to build, instead get errors about missing 
omtool_Prefix.pch

What version of the product are you using? On what operating system?
Xcode 3.2 on OS-X 10.6.2, but likely doesn't matter


Please provide any additional information below.
I've attached a diff showing what I changed in the xcode project order to build 
openmeta cleanly.  
(This includes adding OPEN_META_NO_UI=1 to the preprocessor directives, which 
arguably 
should be the default)

What steps will reproduce the problem?
1. Run ./openmeta

Hi the commandline client is still saying it is V0.1, even though I 
downloaded the latest version, could you update the version string.

What steps will reproduce the problem?
1. Add a tag to a file using a version of OpenMeta prior to r24 (i.e. a version 
that only saves 'last 
tagged' timestamps using Apple's namespace)
2. Read this file's tags using the latest version of OpenMeta (r50)

What is the expected output? What do you see instead?
Expected to get the added tag, instead don't get it.

Please provide any additional information below.

The problem seems to be that OpenMetaBackup's 
-copyTagsFromOldKeyTokMDItemOMIfNeeded: only 
reads `org.openmetainfo.time:kOMUserTags` and 
`org.openmetainfo.time:kMDItemOMUserTags` but 
not `com.apple.metadata:kOMUserTagTime`, and older versions of the library 
don't use the 
org.openmetainfo namespace at all, so only the last attribute of these will be 
set. This will result in it 
not even attempting to copy the tags over to the new namespace and then in the 
end not finding any 
tags on the file.

Hi Tom,

Could you please post the openmeta command line program in the downloads 
section of this site. 
It would be nice to be able to get access to it, and having it here makes good 
sense to my mind. :)

What steps will reproduce the problem?

Run the openmeta CLI executable on an untagged file


What is the expected output? What do you see instead?

Expected output: an empty string (I presume?)
Instead:

$ openmeta -t -p SML000465.pdf 
2012-11-13 11:42:16.250 openmeta[22559:707] *** Terminating app due to uncaught 
exception 'NSInvalidArgumentException', reason: '*** -[NSFileManager 
fileSystemRepresentationWithPath:]: nil or empty path argument'
*** Call stack at first throw:
(
    0   CoreFoundation                      0x99ec712b __raiseError + 219
    1   libobjc.A.dylib                     0x97cec52e objc_exception_throw + 230
    2   CoreFoundation                      0x99e26bbb +[NSException raise:format:] + 139
    3   Foundation                          0x92fc6599 -[NSFileManager fileSystemRepresentationWithPath:] + 122
    4   Foundation                          0x92fc6510 -[NSString(NSPathUtilities) fileSystemRepresentation] + 62
    5   openmeta                            0x0000af71 +[OpenMetaBackup hashString:] + 29
    6   openmeta                            0x000075b7 +[OpenMetaBackup calculateBackupFileName:] + 127
    7   openmeta                            0x0000970e +[OpenMetaBackup restoreMetadataSearchForFile:withDelay:] + 52
    8   openmeta                            0x00007944 +[OpenMetaBackup restoreMetadata:] + 49
    9   openmeta                            0x00004250 +[OpenMeta getUserTags:error:] + 59
    10  openmeta                            0x00002e02 TagsAsString + 62
    11  openmeta                            0x00003700 main + 1903
    12  openmeta                            0x000029f2 start + 54
)
Trace/BPT trap: 5

What version of the product are you using? On what operating system?

$ openmeta
openmeta version 0.1 by Tom Andersen code.google.com/p/openmeta/

Prebuilt executable downloaded on Nov 13, 2012.


Please provide any additional information below.

OSX 10.8.2. As soon as I add tags to the file, the crash goes away.

What steps will reproduce the problem?
1. from terminal run openssl sha1 on the downloaded openmeta_commandline_1.3.0 
zip file 
2.
3.

What is the expected output? What do you see instead?
expect the published she 1 number on webiste
I get  44466f75d3a9c2077f6aefcd85d877185710683c


What version of the product are you using? On what operating system?


Please provide any additional information below.

What steps will reproduce the problem?
1. Run openmeta from the Terminal


What is the expected output? What do you see instead?

expected: openmeta version 1.3.0 by Tom Andersen code.google.com/p/openmeta/ 
shown: openmeta version 0.1 by Tom Andersen code.google.com/p/openmeta/ 



What version of the product are you using? On what operating system?
1.3.0.
OS X Lion

What steps will reproduce the problem?
1. openmeta -a foo bar -p PATH[s]
2. openmeta -s foo bar -p PATH[s]

What is the expected output? if -a foo adds a tag and -s clears tags, then -sa 
foo should set tags

What do you see instead? -s foo sets tags
What version of the product are you using? 0.1
On what operating system? MacOSX 10.5

[deleted issue]