Skip to content

Python3 fixes - #1

Open
jaysonlarose wants to merge 3 commits into
tungol:masterfrom
jaysonlarose:master
Open

Python3 fixes#1
jaysonlarose wants to merge 3 commits into
tungol:masterfrom
jaysonlarose:master

Conversation

@jaysonlarose

Copy link
Copy Markdown

I'm getting the feeling I might be the only person still using this library for anything.
Anyways, here's some "not very pretty, but it's something" fixes for anyone who cares about it.

@tungol

tungol commented Jul 26, 2021

Copy link
Copy Markdown
Owner

I'm surprised (but pleased) to find that anyone has used this at all! I switched over to the standard library myself once that gained support for binary plists. Do you have a particular use case that's still unsupported by plistlib? I'd be interested to know more.

I'll take a look at the MR when I find some time to do so.

@jaysonlarose

Copy link
Copy Markdown
Author

I didn't realize that the standard plistlib library had support for binary plists! What I've been using bplistlib for originally started out as a crude implementation of MacOS Finder tags under Linux (a command-line tool, Nautilus plugin, and some simple gtk+python UI bits), but somehow got turned into an sqlite-backed metadata store along the way... nothing I've ever felt comfortable releasing because it's surprisingly difficult to make sure that a filesystem inode hasn't been recycled without support for something like a filesystem birth time... and only a few filesystems support that (and make that data available to userspace... I'm looking at YOU, ZFS).... At it's heart, my "tags" attribute is still being stored as a binary plist, just like you'd find on MacOS, except it's no longer a filesystem attribute...

I just did a little experiment, and bplistlib seems to encode the data differently than plistlib, I kind of want to say it's using UTF16 instead of UTF8:

>>> plistlib.dumps(jtag.export_plisttags(['Orange', 'image', 'not:a duck']), fmt=plistlib.PlistFormat.FMT_BINARY)
b'bplist00\xa3\x01\x02\x03UimageZnot:a duckXOrange\n7\x08\x0c\x12\x1d\x00\x00\x00\x00\x00\x00\x01\x01\x00\x00\x00\x00\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00&'
>>> bplistlib.dumps(jtag.export_plisttags(['Orange', 'image', 'not:a duck']), binary=True)
b'bplist00\xa3\x01\x02\x03e\x00i\x00m\x00a\x00g\x00ej\x00n\x00o\x00t\x00:\x00a\x00 \x00d\x00u\x00c\x00kh\x00O\x00r\x00a\x00n\x00g\x00e\x00\n\x007\x08\x0c\x17,\x00\x00\x00\x00\x00\x00\x01\x01\x00\x00\x00\x00\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00='

I remember when I first wrote this stuff I was pretty concerned about getting binary plist data that looked just like the stuff that MacOS was creating, but at this point in time, I don't know which method is more correct! shrugs

I suppose the next time I've got a Mac booted up, I'll check to see how they're storing their tag data these days, and that may or may not result in me saying "sayounara" to bplistlib. In either case, I'd like to thank you for writing it, because for quite a while there, it was the most "correct" implementation I could find!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants