Re: [MlMt] 5933: Dragging files into a folder => files are locked (immutable set)
Actually, I think that the solution you adopted was correct even in principle: attachments are part of an inbound email message, and should not be overwritten. If nothing else, what if for some reason the message was refetched from the IMAP server? What if you look at the attachment from one device, which does its own IMAP fetches, after editing it on another? I'd always assumed that attachments were locked; I was glad when MailMate finally implemented it. On 26 Jan 2023, at 6:16, Benny Kjær Nielsen wrote: On 7 Jan 2023, at 13:35, Robert M. Münch wrote: I see this effect I think since I use 5933. The change is in r5927 (November 10th, 2022). I do exactly the same as in the past, but now is looks like files are somehow locked by MM. Checking the file attributes I see that the *Immutable* flag is set. Is this a known problem? How to fix/workaround it? I can see this developed into a very large thread. Someone found the workaround, but I repeat it here to make sure it's more easily found: defaults write com.freron.MailMate MmAttachmentsCacheImmutableStateDisabled -bool YES But it's only to be used by users who understand that attachments are saved in a *temporary* location which can be deleted at any time. It just doesn't happen very often. I can add that the change was motivated by a user working on a document for weeks (possibly hundreds of hours). The corresponding email was later deleted and MailMate cleaned up by also removing temporary files related to the email. Note that the cache is not part of a Time Machine backup. The file could not be salvaged. I have some notes on how this behavior could be improved, but the quick/safest fix was to simply disallow it. -- Benny https://urldefense.proofpoint.com/v2/url?u=https-3A__freron.com_become-5Fa-5Fmailmate-5Fpatron_=DwIDaQ=009klHSCxuh5AI1vNQzSO0KGjl4nbi2Q0M1QLJX9BeE=jMObdJSnQpbSLekl2NjvrJVVxCKbmtg8cvi5143NF8Q=CVUdP8bBLz7fRhNlLBI-ZlHpQxtZBnKht5oCemq3-XPvK8y6raf-Ua5kpSo2unz8=aXCUwTv4z3dPfQejXS5T4fwYNpPguD6bxo9S4XBFA64=___ mailmate mailing list mailmate@lists.freron.com https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.freron.com_listinfo_mailmate=DwIGaQ=009klHSCxuh5AI1vNQzSO0KGjl4nbi2Q0M1QLJX9BeE=jMObdJSnQpbSLekl2NjvrJVVxCKbmtg8cvi5143NF8Q=CVUdP8bBLz7fRhNlLBI-ZlHpQxtZBnKht5oCemq3-XPvK8y6raf-Ua5kpSo2unz8=Y_VFN7KmNaHukVMnC6bkYIeo4tQuJ0NAJiiUq0lORIs= —Steve Bellovin, https://www.cs.columbia.edu/~smb ___ mailmate mailing list mailmate@lists.freron.com https://lists.freron.com/listinfo/mailmate
Re: [MlMt] 5933: Dragging files into a folder => files are locked (immutable set)
Although not exactly the same issue I have recently witnessed that some attachements would have the invisible property set (on what I can only categorise as randomly). Can’t really reproduce it but definitely happens. On 26 Jan 2023, at 12:16, Benny Kjær Nielsen wrote: On 7 Jan 2023, at 13:35, Robert M. Münch wrote: I see this effect I think since I use 5933. The change is in r5927 (November 10th, 2022). I do exactly the same as in the past, but now is looks like files are somehow locked by MM. Checking the file attributes I see that the *Immutable* flag is set. Is this a known problem? How to fix/workaround it? I can see this developed into a very large thread. Someone found the workaround, but I repeat it here to make sure it's more easily found: defaults write com.freron.MailMate MmAttachmentsCacheImmutableStateDisabled -bool YES But it's only to be used by users who understand that attachments are saved in a *temporary* location which can be deleted at any time. It just doesn't happen very often. I can add that the change was motivated by a user working on a document for weeks (possibly hundreds of hours). The corresponding email was later deleted and MailMate cleaned up by also removing temporary files related to the email. Note that the cache is not part of a Time Machine backup. The file could not be salvaged. I have some notes on how this behavior could be improved, but the quick/safest fix was to simply disallow it. -- Benny https://freron.com/become_a_mailmate_patron/ ___ mailmate mailing list mailmate@lists.freron.com https://lists.freron.com/listinfo/mailmate___ mailmate mailing list mailmate@lists.freron.com https://lists.freron.com/listinfo/mailmate
Re: [MlMt] 5933: Dragging files into a folder => files are locked (immutable set)
On 7 Jan 2023, at 13:35, Robert M. Münch wrote: I see this effect I think since I use 5933. The change is in r5927 (November 10th, 2022). I do exactly the same as in the past, but now is looks like files are somehow locked by MM. Checking the file attributes I see that the *Immutable* flag is set. Is this a known problem? How to fix/workaround it? I can see this developed into a very large thread. Someone found the workaround, but I repeat it here to make sure it's more easily found: defaults write com.freron.MailMate MmAttachmentsCacheImmutableStateDisabled -bool YES But it's only to be used by users who understand that attachments are saved in a *temporary* location which can be deleted at any time. It just doesn't happen very often. I can add that the change was motivated by a user working on a document for weeks (possibly hundreds of hours). The corresponding email was later deleted and MailMate cleaned up by also removing temporary files related to the email. Note that the cache is not part of a Time Machine backup. The file could not be salvaged. I have some notes on how this behavior could be improved, but the quick/safest fix was to simply disallow it. -- Benny https://freron.com/become_a_mailmate_patron/ ___ mailmate mailing list mailmate@lists.freron.com https://lists.freron.com/listinfo/mailmate
Re: [MlMt] 5933: Dragging files into a folder => files are locked (immutable set)
As a retired software engineer, I can say this is nowhere close to the most fiery response I’ve ever received. Indeed, I got a little chuckle out of it, and I can appreciate the subtle difficulties of communicating clearly across languages (though I do speak a little German). BUT, I will observe that this mailing list is populated by people who are interested in MailMate, and who take the time to share what they know. None of us are paid tech-support. Unless a message is signed by Benny himself it’s gossip, not gospel. It would be helpful to read comments with a generous eye, and respond with a gentle hand. It was very helpful to learn via John Doherty’s follow-up response that one can hold the option-key when clicking the download button to get a “Save As…” dialog. This is the kind of thing that makes this email forum so good. And, of course there’s always another hidden setting under the hood for the pros, so that’s great, too. On 20 Jan 2023, at 3:06, Robert M. Münch wrote: On 12 Jan 2023, at 2:52, Glenn Parker wrote: I think “it’s a feature, not a bug”, as they say. Well, then that's an awful non-intuitive feature, reducing productivity and annoying me many times per day. I recall seeing a comment about this in release notes, and it made sense. No, it doesn't. The attachment files that MailMate creates in its local cache are read-only. One should *not* be editing those files. I don't and I don't plan to do that. Dragging the file (I didn’t even realize that worked) must be copying the cached file exactly, including the newly restrictive permissions. Why *must* it be copied that way? When I drag the file to another location, I clearly say: *I want to work with that file at this place.* I don't need any software that tries to think for me or protect me from doing what I want. At least, this super annoying feature should be an option, like: *Keep read-only flag to reduce my productivity* To get a copy to work on, just click on the handy “download” button right next to the filename instead, which will make an editable copy. Unfortunately, that *download button* doesn't know where I want to put that file. So it goes to the download folder, and I need to pick it from there, move it around, etc. That's violating the only relevant KPI in any application: *number of clicks to result* Benny, please revert this ASAP or make it optional. This has the potential to move away from MM because this is really driving me nuts. Viele Grüsse. Robert___ mailmate mailing list mailmate@lists.freron.com https://lists.freron.com/listinfo/mailmate Glenn P. Parker glenn.par...@comcast.net ___ mailmate mailing list mailmate@lists.freron.com https://lists.freron.com/listinfo/mailmate
Re: [MlMt] 5933: Dragging files into a folder => files are locked (immutable set)
On 23 Jan 2023, at 10:23, John Doherty via mailmate wrote: > On Sun 2023-01-22 04:15 PM MST -0700, wrote: > >> My need, and I expect this is shared by many, is to give attachments a >> useful name before saving to their proper home. > > I noticed today (as a result of reading this thread) that if you hold the > option key down when you click on the "Save" button for the attachment, you > are presented with a normal "Save As..." dialog and can put the attachment > anywhere you want with whatever name you want. > > I just guessed that this was likely to work this way and lo and behold, it > did. > I like it ✅ Confirming this also works via “Quick Look Attachment” where pressing the option key while clicking on “Open With Preview” lets you rename and/or move the opened document. Regards Gavan ___ mailmate mailing list mailmate@lists.freron.com https://lists.freron.com/listinfo/mailmate
Re: [MlMt] 5933: Dragging files into a folder => files are locked (immutable set)
Apologies for miscasting… to the extent that makes sense, read Malcolm where I have written Robert, otherwise the names are meant as placeholders for generic roles and, are in no way to be interpreted as applying to any real person past or present. ;) On 23 Jan 2023, at 10:15, Gavan Schneider wrote: On 23 Jan 2023, at 8:05, Malcolm Fitzgerald wrote: On 23 Jan 2023, at 9:15, Robert M. Münch wrote: On 20 Jan 2023, at 9:06, Robert M. Münch wrote: At least, this super annoying feature should be an option, like: Keep read-only flag to reduce my productivity Well, it is, reading the notes helps: New: Attachments in the cache are now always saved in a locked state. This can be disabled at your own risk: MmAttachmentsCacheImmutableStateDisabled As someone who is regularly asked to assist when an email attachment has been modified this default makes so much sense. Knowledgable users can modify their settings to suit themselves, everyone else gets the benefits of a safe setting. Thank you for reading the notes a lot better than myself, and now I will head into the “Hidden Preferences” zone for the first time. Let’s see… Hmmm MailMate Help gives an example: gavan@Rosebud ~> defaults read com.freron.MailMate MmDefaultBccHeader 2023-01-23 09:08:54.144 defaults[35710:3326831] The domain/default pair of (com.freron.MailMate, MmDefaultBccHeader) does not exist Not a good start, and likely to produce many serious problems if dabbling continues. Recipe anyone? My need, and I expect this is shared by many, is to give attachments a useful name before saving to their proper home. The name change is needed for those companies who think they are so important in my life that only they would have an attachment called “Statement”, and that I will only ever need one! Another case is for when an invoice attachment has been entered in “the books” and saved in the relevant folder — I preface the file name with the accounts reference number. Many other use cases are easy enough to imagine. This is not risky behaviour and no-one needs to be protected from it. And, while Robert makes the case that users are not always happy when they have made some changes to attachments, there may be good reasons why they attempted a change. Basically, in some cases, help will be needed to repair an error in an otherwise necessary process. Which likely means, down the track, Robert and others, will be asked to remove this barrier to normal processes, and, given humans are involved, occasionally have to help when the user makes a mistake while doing what they were meant to do. Anyway the default setting is now in what could be considered “least change == least harm” which sounds good for what is, as far as I am concerned, a , and is only getting in the way. Propose: == This setting becomes the first to be alterable via the UI under a new tab “Advanced” in the “MailMate>Settings…” interface Or, maybe better: = When an enclosure is opened with the “Quick Look Attachment” process, and then “Open with Preview” is selected I get a *copy* of the attachment which is not locked. The original attachment can stay in place and be there for any salvage operations as needed. And, instead of the “filename (copy).pdf” name, may I suggest “filename.3456.pdf”, where 3456 is the number given to the message .eml file. This is so Spotlight can help me find the relevant email unless it has already been deleted. Regards Gavan Schneider —— Gavan Schneider, Sodwalls, NSW, Australia Explanations exist; they have existed for all time; there is always a well-known solution to every human problem — neat, plausible, and wrong. — H. L. Mencken, 1920 ___ mailmate mailing list mailmate@lists.freron.com https://lists.freron.com/listinfo/mailmate ___ mailmate mailing list mailmate@lists.freron.com https://lists.freron.com/listinfo/mailmate
Re: [MlMt] 5933: Dragging files into a folder => files are locked (immutable set)
On Sun 2023-01-22 04:15 PM MST -0700, wrote: My need, and I expect this is shared by many, is to give attachments a useful name before saving to their proper home. I noticed today (as a result of reading this thread) that if you hold the option key down when you click on the "Save" button for the attachment, you are presented with a normal "Save As..." dialog and can put the attachment anywhere you want with whatever name you want. I just guessed that this was likely to work this way and lo and behold, it did. ___ mailmate mailing list mailmate@lists.freron.com https://lists.freron.com/listinfo/mailmate
Re: [MlMt] 5933: Dragging files into a folder => files are locked (immutable set)
On 23 Jan 2023, at 8:05, Malcolm Fitzgerald wrote: On 23 Jan 2023, at 9:15, Robert M. Münch wrote: On 20 Jan 2023, at 9:06, Robert M. Münch wrote: At least, this super annoying feature should be an option, like: Keep read-only flag to reduce my productivity Well, it is, reading the notes helps: New: Attachments in the cache are now always saved in a locked state. This can be disabled at your own risk: MmAttachmentsCacheImmutableStateDisabled As someone who is regularly asked to assist when an email attachment has been modified this default makes so much sense. Knowledgable users can modify their settings to suit themselves, everyone else gets the benefits of a safe setting. Thank you for reading the notes a lot better than myself, and now I will head into the “Hidden Preferences” zone for the first time. Let’s see… Hmmm MailMate Help gives an example: gavan@Rosebud ~> defaults read com.freron.MailMate MmDefaultBccHeader 2023-01-23 09:08:54.144 defaults[35710:3326831] The domain/default pair of (com.freron.MailMate, MmDefaultBccHeader) does not exist Not a good start, and likely to produce many serious problems if dabbling continues. Recipe anyone? My need, and I expect this is shared by many, is to give attachments a useful name before saving to their proper home. The name change is needed for those companies who think they are so important in my life that only they would have an attachment called “Statement”, and that I will only ever need one! Another case is for when an invoice attachment has been entered in “the books” and saved in the relevant folder — I preface the file name with the accounts reference number. Many other use cases are easy enough to imagine. This is not risky behaviour and no-one needs to be protected from it. And, while Robert makes the case that users are not always happy when they have made some changes to attachments, there may be good reasons why they attempted a change. Basically, in some cases, help will be needed to repair an error in an otherwise necessary process. Which likely means, down the track, Robert and others, will be asked to remove this barrier to normal processes, and, given humans are involved, occasionally have to help when the user makes a mistake while doing what they were meant to do. Anyway the default setting is now in what could be considered “least change == least harm” which sounds good for what is, as far as I am concerned, a , and is only getting in the way. Propose: == This setting becomes the first to be alterable via the UI under a new tab “Advanced” in the “MailMate>Settings…” interface Or, maybe better: = When an enclosure is opened with the “Quick Look Attachment” process, and then “Open with Preview” is selected I get a *copy* of the attachment which is not locked. The original attachment can stay in place and be there for any salvage operations as needed. And, instead of the “filename (copy).pdf” name, may I suggest “filename.3456.pdf”, where 3456 is the number given to the message .eml file. This is so Spotlight can help me find the relevant email unless it has already been deleted. Regards Gavan Schneider —— Gavan Schneider, Sodwalls, NSW, Australia Explanations exist; they have existed for all time; there is always a well-known solution to every human problem — neat, plausible, and wrong. — H. L. Mencken, 1920 ___ mailmate mailing list mailmate@lists.freron.com https://lists.freron.com/listinfo/mailmate
Re: [MlMt] 5933: Dragging files into a folder => files are locked (immutable set)
On 23 Jan 2023, at 9:15, Robert M. Münch wrote: On 20 Jan 2023, at 9:06, Robert M. Münch wrote: At least, this super annoying feature should be an option, like: *Keep read-only flag to reduce my productivity* Well, it is, reading the notes helps: *New: Attachments in the cache are now always saved in a locked state. This can be disabled at your own risk: MmAttachmentsCacheImmutableStateDisabled* As someone who is regularly asked to assist when an email attachment has been modified this default makes so much sense. Knowledgable users can modify their settings to suit themselves, everyone else gets the benefits of a safe setting. thank you, Malcolm ___ mailmate mailing list mailmate@lists.freron.com https://lists.freron.com/listinfo/mailmate
Re: [MlMt] 5933: Dragging files into a folder => files are locked (immutable set)
On 20 Jan 2023, at 9:06, Robert M. Münch wrote: > At least, this super annoying feature should be an option, like: *Keep > read-only flag to reduce my productivity* Well, it is, reading the notes helps: *New: Attachments in the cache are now always saved in a locked state. This can be disabled at your own risk: MmAttachmentsCacheImmutableStateDisabled* I take the risk! Viele Grüsse. Robert signature.asc Description: OpenPGP digital signature ___ mailmate mailing list mailmate@lists.freron.com https://lists.freron.com/listinfo/mailmate
Re: [MlMt] 5933: Dragging files into a folder => files are locked (immutable set)
On 12 Jan 2023, at 2:52, Glenn Parker wrote: > I think “it’s a feature, not a bug”, as they say. Well, then that's an awful non-intuitive feature, reducing productivity and annoying me many times per day. > I recall seeing a comment about this in release notes, and it made sense. No, it doesn't. > The attachment files that MailMate creates in its local cache are read-only. > One should *not* be editing those files. I don't and I don't plan to do that. > Dragging the file (I didn’t even realize that worked) must be copying the > cached file exactly, including the newly restrictive permissions. Why *must* it be copied that way? When I drag the file to another location, I clearly say: *I want to work with that file at this place.* I don't need any software that tries to think for me or protect me from doing what I want. At least, this super annoying feature should be an option, like: *Keep read-only flag to reduce my productivity* > To get a copy to work on, just click on the handy “download” button right > next to the filename instead, which will make an editable copy. Unfortunately, that *download button* doesn't know where I want to put that file. So it goes to the download folder, and I need to pick it from there, move it around, etc. That's violating the only relevant KPI in any application: *number of clicks to result* Benny, please revert this ASAP or make it optional. This has the potential to move away from MM because this is really driving me nuts. Viele Grüsse. Robert signature.asc Description: OpenPGP digital signature ___ mailmate mailing list mailmate@lists.freron.com https://lists.freron.com/listinfo/mailmate
Re: [MlMt] 5933: Dragging files into a folder => files are locked (immutable set)
On 7 Jan 2023, at 7:35, Robert M. Münch wrote: I see this effect I think since I use 5933. I do exactly the same as in the past, but now is looks like files are somehow locked by MM. Checking the file attributes I see that the *Immutable* flag is set. Is this a known problem? How to fix/workaround it? I think “it’s a feature, not a bug”, as they say. I recall seeing a comment about this in release notes, and it made sense. The attachment files that MailMate creates in its local cache are read-only. One should *not* be editing those files. Dragging the file (I didn’t even realize that worked) must be copying the cached file exactly, including the newly restrictive permissions. To get a copy to work on, just click on the handy “download” button right next to the filename instead, which will make an editable copy. Glenn P. Parker glenn.par...@comcast.net ___ mailmate mailing list mailmate@lists.freron.com https://lists.freron.com/listinfo/mailmate
Re: [MlMt] 5933: Dragging files into a folder => files are locked (immutable set)
On 7 Jan 2023, at 23:35, Robert M. Münch wrote: > I see this effect I think since I use 5933. I do exactly the same as in the > past, but now is looks like files are somehow locked by MM. Checking the file > attributes I see that the Immutable flag is set. > > Is this a known problem? How to fix/workaround it? > And I thought it was just me who had messed something up! Yes same problem, same MlMt build, likely macOS Ventura related. So far no “work around” at my place… but I eventiually get the file where I want it after a second/yhird? menu>move file (in Preview) Anybody else? Regards Gavan Schneider —— Gavan Schneider, Sodwalls, NSW, Australia Explanations exist; they have existed for all time; there is always a well-known solution to every human problem — neat, plausible, and wrong. — H. L. Mencken, 1920 signature.asc Description: OpenPGP digital signature ___ mailmate mailing list mailmate@lists.freron.com https://lists.freron.com/listinfo/mailmate
[MlMt] 5933: Dragging files into a folder => files are locked (immutable set)
I see this effect I think since I use 5933. I do exactly the same as in the past, but now is looks like files are somehow locked by MM. Checking the file attributes I see that the *Immutable* flag is set. Is this a known problem? How to fix/workaround it? -- Robert M. Münch Note: The .ASC file contains a digital PGP signature of this email. It can be used to check that this email is from me and was not changed since I wrote it. Hinweis: Die .ASC Datei enthält eine digitale PGP Signatur dieser Email. Mit dieser kann überprüft werden, dass diese Email von mir geschrieben und seitdem nicht verändert wurde. signature.asc Description: OpenPGP digital signature ___ mailmate mailing list mailmate@lists.freron.com https://lists.freron.com/listinfo/mailmate
