I have been receiving errors from pgdumplib and have boiled down the problem to how the output of pg_dump is redirected.
This is what I would like to do, but it consistently fails with RuntimeError: Unsupported data format:
F=/tmp/test_Fc_format.dump
ssh codimd "sudo -u codimd bash -c 'cd /; pg_dump -d codimd -Fc'" >$F
python -c "import pgdumplib; dump = pgdumplib.load('$F')"
I can work around the problem by redirecting the file on the remote machine. This sequence works consistently:
F=/tmp/test_Fc_format.dump
ssh codimd "sudo -u codimd bash -c 'cd /; pg_dump -d codimd -Fc >/tmp/934354 && cat /tmp/934354'" >$F
python -c "import pgdumplib; dump = pgdumplib.load('$F')"
Note that the only difference is that the second sequence adds >/tmp/934354 && cat /tmp/934354, i.e. redirecting the output of pg_dump to a file on the remote machine first, and then sending that to stdout. In both cases, the resulting file is the same size (though not identical because the database is online).
Both local and remote machines run Ubuntu 20.04.
Why is this extra step necessary, and is there a better way to solve this issue?
Update 1:
This, too, gives the error:
F=/tmp/test_Fc_format.dump
ssh codimd "sudo -u codimd bash -c 'cd /; pg_dump -d codimd -Fc |tee /tmp/934354 >/dev/null && cat /tmp/934354'" >$F
python -c "import pgdumplib; dump = pgdumplib.load('$F')"
In other words, to work, pg_dump seems to require a redirect to a local file or the -f option.
Update 2:
Here is the full list of differences between the bad and good version of the database, after using hd on each (note pg_dump never produces the same output twice):
2c2
< 00000010 00 11 00 00 00 00 19 00 00 00 00 16 00 00 00 00 |................|
---
> 00000010 00 2e 00 00 00 00 19 00 00 00 00 16 00 00 00 00 |................|
349c349
< 000015c0 31 38 01 01 00 00 00 01 00 00 00 00 00 00 00 00 |18..............|
---
> 000015c0 31 38 01 01 00 00 00 02 b0 30 00 00 00 00 00 00 |18.......0......|
370c370
< 00001710 31 34 01 01 00 00 00 01 00 00 00 00 00 00 00 00 |14..............|
---
> 00001710 31 34 01 01 00 00 00 02 1e 5f 00 00 00 00 00 00 |14......._......|
387c387
< 00001820 00 00 01 00 00 00 00 00 00 00 00 00 b7 0b 00 00 |................|
---
> 00001820 00 00 02 21 d9 60 00 00 00 00 00 00 b7 0b 00 00 |...!.`..........|
399c399
< 000018e0 01 00 00 00 00 00 00 00 00 00 bf 0b 00 00 00 01 |................|
---
> 000018e0 02 91 0a 4c 01 00 00 00 00 00 bf 0b 00 00 00 01 |...L............|
412,413c412,413
< 000019b0 03 00 00 00 32 32 30 01 01 00 00 00 01 00 00 00 |....220.........|
< 000019c0 00 00 00 00 00 00 ba 0b 00 00 00 01 00 00 00 00 |................|
---
> 000019b0 03 00 00 00 32 32 30 01 01 00 00 00 02 ce 0b 4c |....220........L|
> 000019c0 01 00 00 00 00 00 ba 0b 00 00 00 01 00 00 00 00 |................|
425c425
< 00001a80 35 01 01 00 00 00 01 00 00 00 00 00 00 00 00 00 |5...............|
---
> 00001a80 35 01 01 00 00 00 02 0b ee 4c 01 00 00 00 00 00 |5........L......|
438c438
< 00001b50 00 00 01 00 00 00 00 00 00 00 00 00 b8 0b 00 00 |................|
---
> 00001b50 00 00 02 28 ee 4c 01 00 00 00 00 00 b8 0b 00 00 |...(.L..........|
456c456
< 00001c70 01 00 00 00 01 00 00 00 00 00 00 00 00 00 c7 0b |................|
---
> 00001c70 01 00 00 00 02 45 ee 4c 01 00 00 00 00 00 c7 0b |.....E.L........|
Update 3:
It turns out that this has nothing to do with ssh. I think pg_dump requires a seekable file as output. Here I demonstrate that inserting |cat before redirecting the output file causes the file to be corrupted. If true, is this a bug in pg_dump?
$ pg_dump -d codimd -Fc >/tmp/good
$ python3 -c "import pgdumplib; dump = pgdumplib.load('/tmp/good')"
$ # no error
$ pg_dump -d codimd -Fc |cat >/tmp/bad
$ python3 -c "import pgdumplib; dump = pgdumplib.load('/tmp/bad')"
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "/usr/local/lib/python3.8/dist-packages/pgdumplib/__init__.py", line 24, in load
return dump.Dump(converter=converter).load(filepath)
File "/usr/local/lib/python3.8/dist-packages/pgdumplib/dump.py", line 254, in load
raise RuntimeError('Unsupported data format')
RuntimeError: Unsupported data format
$
Some testing on my end:
F=test_dmp.out
pg_dump -d test -U postgres -Fc > $F | ls -al test_dmp.out
-rw-r--r-- 1 aklaver users 0 Sep 30 14:06 test_dmp.out
pg_dump -d test -U postgres -Fc > temp_file.out && cat temp_file.out > $F | ls -al test_dmp.out
-rw-r--r-- 1 aklaver users 97488 Sep 30 14:08 test_dmp.out
pg_dump -d test -U postgres -Fc -f $F | ls -al test_dmp.out
-rw-r--r-- 1 aklaver users 97488 Sep 30 14:08 test_dmp.out
I know that not an answer as to why > does not work, but it gives an alternative. For some reason > creates an empty file. The other options do not.
UPDATE.
It seems to have something to do with the SSH transfer:
F=test_dump.out
#Using local only.
pg_dump -d test -U postgres -Fc > $F
python -c "import pgdumplib; dump = pgdumplib.load('$F'); print('Database: {}'.format(dump.dbname))"
Database: test
#Using SSH, different database
ssh arkansas "sudo -u aklaver bash -c 'cd /; pg_dump -d redmine -U postgres -Fc'" >$F
python -c "import pgdumplib; dump = pgdumplib.load('$F'); print('Database: {}'.format(dump.dbname))"
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "/home/aklaver/py_virt/py37/lib/python3.7/site-packages/pgdumplib/__init__.py", line 24, in load
return dump.Dump(converter=converter).load(filepath)
File "/home/aklaver/py_virt/py37/lib/python3.7/site-packages/pgdumplib/dump.py", line 254, in load
raise RuntimeError('Unsupported data format')
RuntimeError: Unsupported data format
#Though the file itself ends up being ok. The below does not error out.
#There seems to be something asynchronous going on. In other words
#pgdumplib is reading the file before it is complete.
pg_restore -f test.sql test_dump.out
I have a set of files which have null bytes roughly at every second byte slot. Further, they have the byte sequence FF FE at the beginning, which needs to be removed. I was given the files (they are actually router configuration files, so plain text), and I have no idea how those bytes got in there. However, the file looks like this, which I found for example here or here, :
FF FE 65 00 6E 00 61 00 62 6C 00 6C 65 00 0D 00
0A 00 63 00 6F 00 6E 00 66 00 69 00 37 00 75 00
72 00 65 00 20 00 74 00 65 00 72 00 6D 00 69 00
Think you can imagine how it goes on. I tried various things to remove the null bytes and the first 2 bytes as well:
sed -i.bak 's/\x00//g' R2.txt does nothing.
LC_ALL=C sed -i.bak 's/\x00//g' R2.txt does nothing.
LC_ALL=C tr < R2.txt -d '\000' > R2-test.txt works, but is not in line.
LC_ALL=C sed -i.bak $'s/\x00//g' R2.txt complains about sed: 1: "s/": unterminated substitute pattern
So... my question is, how to remove the null bytes the first two bytes (FF FE) from this file, inline, on OSX?
Thanks.
you said " null bytes roughly at every second byte slot". This is a clear indication of the file being encoded with "charset=utf-16le" and you will need to convert it to utf-8 , ascii ..etc. try something like the below:
iconv -f "current-encoding" -t "desired-encoding" infile.txt > outfile.txt
I'm working on extracting data from SNMP services. The output looks like this.
experimental.94.4.5.1.6.16.0.0.192.221.13.147.179.0.0.0.0.0.0.0.0.1 = Hex-STRING: 00 00 00 1A 85 95 13 F4
experimental.94.4.5.1.6.16.0.0.192.221.13.147.179.0.0.0.0.0.0.0.0.24 = Hex-STRING: 00 00 10 8E 0C F4 99 1C
experimental.94.4.5.1.6.16.0.0.192.221.31.68.71.0.0.0.0.0.0.0.0.10 = Hex-STRING: 00 00 17 10 45 A5 13 3C
I would like the output to be in three parts.
192.221.13.147.179 1 0000001A859513F4
192.221.13.147.179 24 0000108E0CF4991C
192.221.31.68.71 10 0000171045A5133C
I can accomplish all 3 individually using awk but not all at once.
awk '{print substr($0,28,35)}'
you can use:
awk 'BEGIN{FS="[.: ]"}{print $10"."$11"."$12"."$13"."$14" "$23" "$27$28$29$30$31$32$33$34}'
I have a temperature sensor connected to a *nix system and the typical output is something like:
pi#raspberrypi $ cat /sys/bus/w1/devices/28-00000202070c/w1_slave
c3 00 4b 46 7f ff 0d 10 12 : crc=12 YES
c3 00 4b 46 7f ff 0d 10 12 t=12187
The result comes without any comma, but is assumed that is always coming with 3 digits after the comma, so in this example would be 12.187º.
I have implemented a filter that places a comma after the second char, and it works most of the time:
grep t= | awk '{print $10;}'| sed 's/t\=//g' | sed 's/\([0-9][0-9]\)\([0-9]\)/\1,\2/g'
However, during winter, temperature drops below 10º and my filter returns values like 95,32º (when it should be 9,532º).
Is there any way of counting characters from the right, so I could always count with the 3 digital characters (and avoiding this problem in temperatures below 10º)?
Thanks,
Joaoabs
awk can handle floating point operations:
awk '/t=/ { sub(/t=/,"",$NF); print $NF/1000}' /sys/bus/w1/devices/28-00000202070c/w1_slave
If I understand you correctly, then what you want to do is :
sed 's/\([0-9][0-9][0-9]\)$/,\1/g'
$ in a regex means 'the end' so this searches for 3 digits right at the end of a string and replaces them with comma+the found digits.
(Note: This should be the last part of your pipe, with the beginning unchanged.)
Using awk
awk -F= '/t=/ {print $NF/1000}' /sys/bus/w1/devices/28-00000202070c/w1_slave
12.187
Or store it to a variable:
temp=$(awk -F= '/t=/ {print $NF/1000}' /sys/bus/w1/devices/28-00000202070c/w1_slave)
echo "$temp"
12.187
don't do grep|awk|sed|sed..., try this:
...|awk -F't=' -v OFS='t=' 'NF>1{$2=sprintf("%'\''d",$2)}7'
test with your data:
kent$ echo "c3 00 4b 46 7f ff 0d 10 12 : crc=12 YES
c3 00 4b 46 7f ff 0d 10 12 t=12187"|awk -F't=' -v OFS='t=' 'NF>1{$2=sprintf("%'\''d",$2)}7'
c3 00 4b 46 7f ff 0d 10 12 : crc=12 YES
c3 00 4b 46 7f ff 0d 10 12 t=12,187
awk has the format pattern in 'printf' for your requirement. just use it.
if you just want to have the t= value:
awk -F't=' -v OFS='t=' 'NF>1{printf "%'\''d\n",$2}'
with same input:
kent$ echo "c3 00 4b 46 7f ff 0d 10 12 : crc=12 YES
c3 00 4b 46 7f ff 0d 10 12 t=12187"|awk -F't=' -v OFS='t=' 'NF>1{printf "%'\''d\n",$2}'
12,187
Since Mavericks, OS X has had the ability to tag & colour files in Finder.
Is there any way to add tags to files through Cocoa APIs or via a shell command?
Check out tag, "a command line tool to manipulate tags on Mac OS X 10.9 Mavericks files, and to query for files with those tags". The GitHub repository has installation instructions (there are Homebrew and MacPorts packages).
Sorry for adding another answer, but the one related to setting Label colors was pretty long already. Here is an excerpt from a python script that I use to set the User Tags. It seems to work to make things searchable, but not sure if the tags will show up correctly. Usage is basically:
tagfile.py "Tag Name" FileOrFolderName
Code below.
#! /usr/bin/env python
# -*- coding: utf-8 -*-
""" Write tags to file
Usage:
tagfile.py "TagName" FileName1 FileName2
You can use wildcards for the file name. Use quotes if spaces in tags.
To check if it worked, use xattr -l FileName
"""
import sys
import subprocess
def writexattrs(F,TagList):
""" writexattrs(F,TagList):
writes the list of tags to three xattr fields on a file-by file basis:
"kMDItemFinderComment","_kMDItemUserTags","kMDItemOMUserTags
Uses subprocess instead of xattr module. Slower but no dependencies"""
Result = ""
plistFront = '<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"><plist version="1.0"><array>'
plistEnd = '</array></plist>'
plistTagString = ''
for Tag in TagList:
plistTagString = plistTagString + '<string>{}</string>'.format(Tag.replace("'","-"))
TagText = plistFront + plistTagString + plistEnd
OptionalTag = "com.apple.metadata:"
XattrList = ["kMDItemFinderComment","_kMDItemUserTags","kMDItemOMUserTags"]
for Field in XattrList:
XattrCommand = 'xattr -w {0} \'{1}\' "{2}"'.format(OptionalTag + Field,TagText.encode("utf8"),F)
if DEBUG:
sys.stderr.write("XATTR: {}\n".format(XattrCommand))
ProcString = subprocess.check_output(XattrCommand, stderr=subprocess.STDOUT,shell=True)
Result += ProcString
return Result
DEBUG = False
if __name__ == "__main__":
if len(sys.argv) < 3:
print __doc__
else:
TagList = [ sys.argv[1] ]
# print TagList
# Or you can hardwire your tags here
# TagList = ['Orange','Green']
FileList = sys.argv[2:]
for FileName in FileList:
writexattrs(FileName, TagList)
I add this answer, because OP asked for a shell script and tagged it bash. I wrote this Automator service, which tags the selected file with the tags of another file. I have added comments to outline the use of bash's interaction with the tags and colours using bash script.
Basics
In scripts both OpenMeta and Mavericks tags can be accessed with the command xattr. Using it without modifiers, $ xattr [file], gives a list of set attributes. $ xattr -h gives a nice guide to usage.
Mavericks' tags are in com.apple.metadata:_kMDItemUserTags, while OpenMeta tags can be in a variety of attributes. Amongst others com.apple.metadata:kOMUserTags, org.openmetainfo:kMDItemOMUserTags and org.openmetainfo:kOMUserTags.
Mavericks handles colours and tags in different attributes, by placing tags in _kMDItemUserTags and colours in FinderInfo for every file. This is a bizarre choice, and it is one of the reasons Finder struggles under the pressure of tagging. If you have 800 files tagged kapow, each in a different folder, and you subsequently choose the colour blue for kapow, Finder has to find and alter attributes for every single file.
You can play around with the oddity by removing the com.apple.FinderInfo attribute from a tagged and coloured file: $ xattr -d com.apple.FinderInfo [file]. The colour will disappear in Finder listings, but the tag (and its colour) remains associated with the file.
Bash script to import tags from another file
In the script, the selected file(s) in Finder is/are saved to the variable $tagless, and the chosen supplier of tags is $tagfull.
TAGFULID=${##}
TAGFUL=${!TAGFULID}
## Use xattr to read all existing tags:
ATTRS=$(xattr "$TAGFUL")
for f in "$#" ## For every selected file in Finder, do:
do
if("$TAGFUL"="$f") ## Is the supplier of tags is amongst the selected files?
then
break
fi
if [[ "$ATTRS" == *kMDItemUserTags* ]] ## Are there tags?
then
## Load tags:
TAGS=$(xattr -px com.apple.metadata:_kMDItemUserTags "$TAGFUL")
## Write tags:
xattr -wx com.apple.metadata:_kMDItemUserTags "$TAGS" "$f"
fi
if [[ "$ATTRS" == *FinderInfo* ]] ## Are there colours?
then
## Load colour:
FINDERINFO=$(xattr -px com.apple.FinderInfo "$TAGFUL")
## Write colour:
xattr -wx com.apple.FinderInfo "$FINDERINFO" "$f"
fi
done
You could give this a shot:
xattr -w com.apple.metadata:_kMDItemUserTags '<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"><plist version="1.0"><array><string>Orange</string><string>Red</string></array></plist>' $currentFile
You'll want to replace $currentFile with the file you'd like to add tags to, and change
<string>Orange</string><string>Red</string>
to a list of whatever tags you want to add.
In Apple's What's New in OS X it states that NSURL handles tags, and the Common File System Resource_Keys gives the required key as NSURLTagNamesKey and states its value is just an array of strings.
This does not cover tags, but for changing label colors, one way to do it is through a command like this:
xattr -wx com.apple.FinderInfo \
0000000000000000000400000000000000000000000000000000000000000000 myfile.txt
The 04 buried in the middle is setting the file color.
Here is a python script which wraps that command lets you set the tag color on a file or series of files:
import sys
import subprocess
def colorizeFile(ColorName,FileName):
ReverseTable = {
"clear" : "01",
"gray" : "03",
"green" : "04",
"purple" : "06",
"blue" : "09",
"yellow" : "0A",
"red" : "0C",
"orange" : "0E",
"c" : "01",
"a" : "03",
"g" : "04",
"p" : "06",
"b" : "09",
"y" : "0A",
"r" : "0C",
"o" : "0E",
}
HexString = 18*"0" + ReverseTable.get(ColorName) + 44*"0"
Xcommand = 'xattr -wx com.apple.FinderInfo {0} {1}'.format(HexString,FileName)
ProcString = subprocess.check_call(Xcommand, stderr=subprocess.STDOUT,shell=True)
if __name__ == "__main__":
if len(sys.argv)<3:
sys.stderr.write(__doc__.format(sys.argv[0]))
else:
Cname = sys.argv[1]
Flist = sys.argv[2:]
for File in Flist:
colorizeFile(Cname.lower(),File)
sys.stderr.write("## Colorized {0} file(s) as {1}\n".format(len(Flist),Cname))
Usage is:
labelcolor.py [color] *.jpg
where [color] is a name or abbreviation as defined below:
clear (c), grAy (a), green (g), purple (p),
blue (b), yellow (y), red (r), orange (o)
The OpenMeta framework is a third-party standard for adding metadata to OS X files using extended attributes. It is used by a number of third-party applications.
Or you can use the XATTR command to manipulate the extended attributes via command line.
Starting with Mavericks, it is possible to get and set color tags in Cocoa, using NSURL.
NSURL has a slew of properties that can be set or read, through the respective setResourceValue:forKey:error: and getResourceValue:forKey:error: methods.
Using the NSURLLabelNumberKey key, you can set the color tags, as follows:
NSURL *fileURL = [NSURL fileURLWithPath:#"/Users/[username]/Documents/[some_file]"];
NSError *resourceError;
if (![fileURL setResourceValue:#(2) forKey:NSURLLabelNumberKey error:&resourceError]) {
NSLog(#"Error while setting file resource: %#", [resourceError localizedDescription]);
}
If this is executed on a file that only has one color, then it clears the current color, and sets the specified color. However, if multiple colors are already set on the file, then it does not clear the existing colors before setting the specified color.
Here is the value-color mapping (on El Capitan):
#(0): None
#(1): Grey
#(2): Green
#(3): Purple
#(4): Blue
#(5): Yellow
#(6): Red
#(7): Orange
I have not been able to set a tag using NSURLLabelColorKey. Here is my experience on El Capitan, with the keys related to 'tags' (Colors):
NSURLLabelNumberKey: can be read/set successfully, with numbers 0-7. Any other number will return an error. If there are multiple tags set, then this will return the index of the first color that is set, as it searches numerically through the indexes 1 through 7. Although you can clear a color in Finder by clicking on the color, programmatically setting a color that is already set does not clear that color.
NSURLLabelColorKey: returns nil, even when a color tag is set for a file. Setting a value with this key has no effect.
NSURLTagNamesKey: returns an array of the color names for the tags that are set.
In Ask Different
With multiple answers, one of which is accepted:
Possible to tag a folder via terminal? (2013-11-15)
Here in Stack Overflow the question arose slightly earlier (2013-11-01) so I'll add my answer here.
openmeta
Open source at https://code.google.com/p/openmeta/source/browse/trunk/trunk/openmeta
The openmeta command appears to take a dual attribute approach, working with both:
com.apple.metadata:kMDItemOMUserTags
com.apple.metadata:_kMDItemUserTags
Example usage
sh-3.2$ sw_vers
ProductName: Mac OS X
ProductVersion: 10.9.5
BuildVersion: 13F1096
sh-3.2$ uname -a
Darwin gpes3e-gjp4.local 13.4.0 Darwin Kernel Version 13.4.0: Wed Mar 18 16:20:14 PDT 2015; root:xnu-2422.115.14~1/RELEASE_X86_64 x86_64
sh-3.2$ date
Sun 26 Jul 2015 08:00:23 BST
sh-3.2$ rm ~/Desktop/test.txt
sh-3.2$ touch ~/Desktop/test.txt
sh-3.2$ xattr -l ~/Desktop/test.txt
sh-3.2$ ./openmeta
openmeta version 0.1 by Tom Andersen code.google.com/p/openmeta/
Usage: openmeta [options] -p PATH[s]
Note that commas are to be used nowhere - tag lists use quotes for two word tags in output
example (list tags and ratings): openmeta -p PATH
example (list tags and ratings multiple): openmeta -p PATH PATH
example (list tags): openmeta -t -p PATH[s]
example (add tags): openmeta -a foo bar -p PATH[s]
example (add tags with spaces): openmeta -a "three word tag" "foo bar" -p PATH[s]
example (set tags): openmeta -s foo bar -p PATH[s]
example (clear all tags): openmeta -s -p PATH[s]
example (set managed): openmeta -m Y -p PATH[s]
example (set rating 0 - 5 stars): openmeta -r 3.5 -p PATH[s]
example (print rating): openmeta -r -p PATH[s]
example (clear rating): openmeta -r 0.0 -p PATH[s]
example (lousy rating): openmeta -r 0.1 -p PATH[s]
sh-3.2$ ./openmeta -a kerfuffle -p ~/Desktop/test.txt
kerfuffle /Users/gjp22/Desktop/test.txt
sh-3.2$ ./openmeta -p ~/Desktop/test.txt
/Users/gjp22/Desktop/test.txt
tags: kerfuffle
rating: none found
sh-3.2$ xattr -l ~/Desktop/test.txt
com.apple.metadata:kMDItemOMUserTagTime:
00000000 62 70 6C 69 73 74 30 30 33 41 BB 64 BD 3C D4 95 |bplist003A.d.<..|
00000010 F2 08 00 00 00 00 00 00 01 01 00 00 00 00 00 00 |................|
00000020 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000030 00 11 |..|
00000032
com.apple.metadata:kMDItemOMUserTags:
00000000 62 70 6C 69 73 74 30 30 A1 01 59 6B 65 72 66 75 |bplist00..Ykerfu|
00000010 66 66 6C 65 08 0A 00 00 00 00 00 00 01 01 00 00 |ffle............|
00000020 00 00 00 00 00 02 00 00 00 00 00 00 00 00 00 00 |................|
00000030 00 00 00 00 00 14 |......|
00000036
com.apple.metadata:_kMDItemUserTags:
00000000 62 70 6C 69 73 74 30 30 A1 01 5B 6B 65 72 66 75 |bplist00..[kerfu|
00000010 66 66 6C 65 0A 30 08 0A 00 00 00 00 00 00 01 01 |ffle.0..........|
00000020 00 00 00 00 00 00 00 02 00 00 00 00 00 00 00 00 |................|
00000030 00 00 00 00 00 00 00 16 |........|
00000038
kOM109SyncDone:
00000000 62 70 6C 69 73 74 30 30 09 08 00 00 00 00 00 00 |bplist00........|
00000010 01 01 00 00 00 00 00 00 00 01 00 00 00 00 00 00 |................|
00000020 00 00 00 00 00 00 00 00 00 09 |..........|
0000002a
sh-3.2$
Limitations of other utilities
Apple Finder, for example.
After using Finder to remove the kerfuffle tag, kerfuffle remains as an OpenMeta tag:
sh-3.2$ date ; xattr -l ~/Desktop/test.txt
Sun 26 Jul 2015 08:02:13 BST
com.apple.metadata:kMDItemOMUserTagTime:
00000000 62 70 6C 69 73 74 30 30 33 41 BB 64 BD 3C D4 95 |bplist003A.d.<..|
00000010 F2 08 00 00 00 00 00 00 01 01 00 00 00 00 00 00 |................|
00000020 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000030 00 11 |..|
00000032
com.apple.metadata:kMDItemOMUserTags:
00000000 62 70 6C 69 73 74 30 30 A1 01 59 6B 65 72 66 75 |bplist00..Ykerfu|
00000010 66 66 6C 65 08 0A 00 00 00 00 00 00 01 01 00 00 |ffle............|
00000020 00 00 00 00 00 02 00 00 00 00 00 00 00 00 00 00 |................|
00000030 00 00 00 00 00 14 |......|
00000036
com.apple.metadata:_kMDItemUserTags:
00000000 62 70 6C 69 73 74 30 30 A0 08 00 00 00 00 00 00 |bplist00........|
00000010 01 01 00 00 00 00 00 00 00 01 00 00 00 00 00 00 |................|
00000020 00 00 00 00 00 00 00 00 00 09 |..........|
0000002a
kOM109SyncDone:
00000000 62 70 6C 69 73 74 30 30 09 08 00 00 00 00 00 00 |bplist00........|
00000010 01 01 00 00 00 00 00 00 00 01 00 00 00 00 00 00 |................|
00000020 00 00 00 00 00 00 00 00 00 09 |..........|
0000002a
sh-3.2$
Understanding those limitations
With attention to domains and naming conventions: Developer thoughts on adopting OpenMeta – Ironic Software (2009-03, and now in the Internet Archive Wayback Machine) reminds us that com.apple.metadata was for use by Apple when OpenMeta (a project not in the apple.com domain) began the Apple-oriented com.apple.metadata:kMDItemOMUserTags approach.
So I should not expect Apple software to gain or maintain compatibility with both approaches to tagging.
Edge cases
In some cases it may be desirable to remove Apple-oriented com.apple.metadata:_kMDItemUserTags tags without removing OpenMeta-oriented com.apple.metadata:kMDItemOMUserTags tags.
However, doing so – programmatically – is probably beyond the scope of the question asked by #nacross.
I just implemented OSXMETADATA in Python to copy OSX finder tags
https://pypi.org/project/osxmetadata/