-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cargo no longer excludes temp files from backups on macOS #7189
Comments
This fixes an accidental regression from rust-lang#6880 identified in rust-lang#7189 by moving where the configuration of backup preferences happens since it was accidentally never happening due to the folder always having been created.
Oops sorry about that, and thanks for the report! Mind testing out #7192 to see if it works for you? |
Hey - that does the trick. This is a neat feature, by the way -- At some point I realized how big these directories were, went to go figure out whether they were in my backups, and realized they were already magically excluded! So, thanks to @kornelski for thinking of this. Some third-party backup software respects that attribute too. |
Ok great, thanks for checking! |
In 1.36.0, cargo no longer excludes directories in
target
from Time Machine backups on macOS machines (see #3884).To reproduce: Delete the
target
directory for some project, and run a build. Runxattr -r target
and note that there is no attributecom.apple.metadata:com_apple_backup_excludeItem
applied to any subdirectories (if nothing has any extended attributes, it will not print anything.) Try the same with a prior version such as 1.35.0, and it will apply that attribute to subdirectories oftarget
.This regression seems to have been introduced in 8258ca4 -- from what I can tell (and it's entirely possible that I'm completely misreading the situation!), the issue is that the directory that is to be excluded from backups upon creation is actually not created in
Layout::prepare
as might be expected -- it winds up being created earlier, inLayout::at
, when it callsopen_rw
on theflock::Filesystem
. Reverting that change would fix the problem, but I hope there might be a more elegant way to fix it that still maintains the spirit of that change (not updating that bit of metadata every time!)The text was updated successfully, but these errors were encountered: