What about make a new one that just like asepsis? #25
Comments
|
honestly, that is the ideal solution. the issue is that asepsis and the underlying mach_override library hook into running system processes, which Apple has steadily been taking steps to prevent. |
|
Many evidences prove that |
|
One source for insight into how the app works that I've looked at many
times is the closed asepsis issues. Darwin, the dev, talks openly about
solutions to solving various problems he's run into.
Whatever you decide to do, a system extension is definitely the way to go
cause it could be used with SIP enabled and even distributed via the app
store and I think it would persist after os updates
…On Wed, Dec 4, 2019, 9:04 PM xiaozhuai, Weihang Ding < ***@***.***> wrote:
Many evidences prove that Finder create and use the .DS_Store, am I
right? So I am going to reverse enginering Finder to see what I can do.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#25?email_source=notifications&email_token=AEI3REMAKPERRQ35TGPONTTQXBVVTA5CNFSM4JVJL7PKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEF7J5HA#issuecomment-561946268>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AEI3RENYG5IXWTQTQMGPP2LQXBVVTANCNFSM4JVJL7PA>
.
|
|
That's true! |
|
@JK3Y Ok, I've spend all my day to work with it. Finally, I found something. https://github.com/xiaozhuai/odourless It works on my Mac. What's your suggestion? |
|
Well, if you just wanted to delete .DS_Store files you could as well write a background daemon which would be watching filesystem changes and delete .DS_Store files after creation. This solution would not be Finder-specific and would not require SIP disabled. |
|
@darwin Yes, I know. You did a good job, Thank you! |
|
@darwin thanks for jumping in the thread! Personally, I really like the DS cage. If my folder views didn't persist when I changed them, it would be pretty frustrating. |
|
@xiaozhuai interesting! I've never heard of Frida before. I admit, I was confused seeing a js and python file in there lol. Haven't tried it yet, but I'm glad you're making progress so quickly, that's awesome. |
|
@JK3Y I will take a look at this file. |
|
@JK3Y I look into
If we can override this function |
|
@darwin What Asepsis does is overriding Am I right? What is this Seems like |
|
@JK3Y @darwin Ok, guys. I was able to make my project odourless redirect all |
|
@xiaozhuai Nice job! Yes, asepsis had a whitelist of processes. In the end it was effective for Finder and mdwrite. Maybe mdwrite changed at some point or it uses DesktopServices indirectly via some of its dependencies. I don't really remember the details. But some additional info can be obtained from the old homepage: https://asepsis.binaryage.com
It used to be that this "folder rename watching" was implemented as kernel extension. Later when they introduced effective filesystem events watching APIs I was able to rewrite it in user space: https://github.com/JK3Y/asepsis/tree/master/daemon |
|
@darwin Yes, |
|
@xiaozhuai great work! have you seen if this solution works on the latest macOS? I'm amazed at how quickly you're making advancements @darwin thanks for pointing me in the right direction. I appreciate your help with this asepsis modernization :) |
|
@JK3Y @darwin Ok, guys. I achieved this. Check https://github.com/xiaozhuai/odourless for more infomation. Tested on Mojave, not tested on Catalina yet. |
|
Tested on Catalina~ It works well. |
|
Hey @xiaozhuai thanks for your work on this. That came out of nowhere. I was starting to worry I might have to accept the If I understand correctly, this is using a similar method as asepsis, but it's a simplification? |
|
@dactylo Yes, as for now, odourless do not have a feature that @darwin mentioned before. That feature is on my plan.
Odourless do use a similar method as asepsis, and it works well on Catalina. But I'd recommend you backup your whole system via TimeMachine before upgrading to Catalina. And if you got a good idea, issue and pr is welcome. |
|
@xiaozhuai Does Odourless require SIP-disabling only for installing, or permanently? |
|
@torarnv |
|
Thanks for the clarification! Do I understand it correctly that an agent that watches added Would it be possible to persist the same Finder customizations in an extended attribute instead? |
|
@torarnv Yes, you are right. |
Some properties are stored in extended attributes in the filesystem, such as file comments and tags, eg: I was thinking that perhaps the info in the Some cursory googling suggests that it's not the case, but it might have changed in recent OS releases, so worth a shot? |
|
@torarnv That may be possible, but what matters is code injection. Code injection needs SIP disabled. If you want to change the behivaor of |
|
If there's a matching extended attribute for the |
|
There are probably some reasons why Apple didn't change implementation of .DS_Store to extended attributes. Most likely legacy reasons. One reason which comes to mind is that extended attributes are not supported on all possible filesystems. But I agree that it would be a more elegant solution (for a typical user who uses HFS+/APFS and does not care about external drives that much). And it would not require background daemon for monitoring folder renames. The downside is that cage directory approach has very simple implementation, but using extended attributes we would have to somehow extract DS_Store and then delete it or something like that. |
Right, this seems like the primary (only) use-case here (for us), so extended attributed would be a good fit. If it is possible, then it seems like a safer and more future proof solution than disabling SIP and interposing Finder, even if it requires a bit more code 😊 |
|
I found this interesting article about xattr support on different filesystems: @torarnv I don't understand how you could implement it using xattr without interposing. When Finder wants to access a .DS_Store file there must be a mechanism which would read it from xattr and present it to Finder as fake .DS_Store. |
|
@torarnv But how can you implement it without interposing? |
|
@darwin The assumption is that Finder natively supports reading the info it needs also from extended attributes, but that it's creating
If that doesn't hold then yes, we'd need interposing, and there's no point in using extended attributes for the sidecar data over a file system jail like Odourless uses. |
|
@torarnv |
|
I don't know if it's possible, I was just brainstorming 😊 Looking at the disassembly of Finder or its frameworks might reveal what extended attributes it supports, and whether they ( |
|
@torarnv You may want to take a look at |
|
I pretty much doubt com.apple.FinderInfo stores the same info as .DS_Store. This[1] commenter claims he knows what is stored in struct FileInfo {
OSType fileType; /* The type of the file */
OSType fileCreator; /* The file's creator */
UInt16 finderFlags; /* ex: kHasBundle, kIsInvisible... */
Point location; /* File's location in the folder */
/* If set to {0, 0}, the Finder will place the item automatically */
UInt16 reservedField; /* (set to 0) */
};
struct ExtendedFileInfo {
SInt16 reserved1[4]; /* Reserved (set to 0) */
UInt16 extendedFinderFlags; /* Extended flags (custom badge, routing info...) */
SInt16 reserved2; /* Reserved (set to 0). Comment ID if high-bit is clear */
SInt32 putAwayFolderID; /* Put away folder ID */
};My observations:
[1] https://eclecticlight.co/2017/12/19/xattr-com-apple-finderinfo-information-for-the-finder/#comment-16241 |
|
@darwin Interesting, thanks for the insight! I didn't have high hopes for it to be possible, but was worth a shot! |
|
Even if it was possible, deleting the .DS_Store would change the modification date of the enclosing folder. That would be undesirable IMO, so that would have to be saved/restored, which I assume would introduce a race condition. |
|
Interesting conversation! I found this issue because I just upgraded to Catalina and (of course) Asepsis stopped working. And Big Sur is coming soon! So, for the record, I'll be happy switching to @xiaozhuai's odourless fork right now, even without the directory-watching-renaming daemon. I really could not care less if my folder metadata is lost when I rename, move or delete them! In fact, I'd be happy to use an even simpler fork that just /dev/null'ed all the damn .DS files, not saving them anywhere! No need for the complexities of a daemon OR extended attributes then! Uber-simplification and at what cost? What "feature" is lost? Where I left the icons on my desktop?? That's is the only one folder I even remotely ever care about where I left the icons: my desktop, and I hardly ever look at that one! I keep my finder in Details view. I DO like that folders "remember" whether I left them sorted by date, or by name, or size -- but I could live without that too! The .DS file pollution is way more aggravating than losing that would be. Rather than a daemon, I'd be thrilled to run a cleanup/pruning script from time to time that compares the caged directories to "reality" and deletes ay that are no longer found, just so the cage doesn't grow in size endlessly -- In fact, I'll contribute that script :-) Long-term, I would pay good $$ for a solution that:
Please -- somebody start a GoFundMe and save me! Oh and it would be nice if the old Asepsis page had a link near the top that pointed (here, for Mojave users, and) to whatever the current workaround is that all of us old Asepsis addicts need to keep us going, since we are so old now that we tend to forget... :-) thanks! -dave |
|
I’m with dave: All my files are cross-platform so I don’t make use of any “MacOS specific” metadata, and as far as I’m concerned all finder windows can be in detail view sorted by name. If I want another view it’s for a specific use. .DS_Store and all the other “dotfiles” can simply not exist and I’m perfectly happy. |
|
In fact, I prefer it. |
|
@davidkaufman If you want deleted .DS_Store anyway than keep it in a cage. There are several ways. It's much easier.
|
I am wondering if we can make a new one that just like asepsis. And how much work will it takes?
For some reason that asepsis not work well and lose maintainance. All we need is a easy to install and easy to use tool to prevent the fucking .DS_Store.
The text was updated successfully, but these errors were encountered: