Opened a file from an email attachment
On save from textmate, I get this error:
The document “BadFactorScoresExample.R” could not be saved.
Failed replacing BadFactorScoresExample.R with /var/folders/66/wrbbw2d11gzds_76wqw367f00000gn/T/TemporaryItems/(A Document Being Saved By TextMate)/BadFactorScoresExample.R: You don’t have permission to save the file “BadFactorScoresExample.R” in the folder “7DBA5AD0-07BF-4399-B649-CDE020317A4B”.
FYI, it also generates errors from commands that need to read/write
On 16 Nov 2019, at 22:16, Timothy Bates wrote:
Opened a file from an email attachment
On save from textmate, I get this error:
The document “BadFactorScoresExample.R” could not be saved.
Apple Mail saves attachments in a Mail Downloads folder that appears to be setup not to be writable (by other applications?).
It’s unclear to me how exactly it is setup, because the classic file mode flags do allow writing, but try command-click the proxy icon, and the folders are badged with a minus symbol:
This could be by design, because really, only Mail should control those folders.
That said, you can disable atomic saving for all but remote volumes by putting this in `~/.tm_properties`:
atomicSave = remoteVolumes
This will make it work because TextMate then doesn’t write a new file, but opens the existing file for (over)writing.
I’m considering making this the default, because with the loss of `exchangedata` (when we moved to APFS) I think there are now too many downsides to atomic saving to make it the default :(
I hope you don't actually make this change... atomic save is desirable, even if you end up losing some metadata.
What are other tools doing? I wonder if you give TM Full Disk Access, does it still throw the error?
I think the below is a bad example, one that's promoted (unfortunately) by Outlook on Windows. You shouldn't (IMO) assume that an attachment is something you can open and write to and save again. If you want to save it, then you should be saving it somewhere other than in the original message. Anything else just leads to eventual data loss and TM shouldn't bend over backwards to facilitate it.
-- Marc Wilson posguy99@gmail.com
On Wed, Apr 15, 2020, at 7:24 PM, Allan Odgaard wrote:
On 16 Nov 2019, at 22:16, Timothy Bates wrote:
Opened a file from an email attachment
On save from textmate, I get this error:
The document “BadFactorScoresExample.R” could not be saved.
Apple Mail saves attachments in a Mail Downloads folder that appears to be setup not to be writable (by other applications?).
It’s unclear to me how exactly it is setup, because the classic file mode flags do allow writing, but try command-click the proxy icon, and the folders are badged with a minus symbol:
This could be by design, because really, only Mail should control those folders.
That said, you can disable atomic saving for all but remote volumes by putting this in `~/.tm_properties`:
`atomicSave = remoteVolumes
`
This will make it work because TextMate then doesn’t write a new file, but opens the existing file for (over)writing.
I’m considering making this the default, because with the loss of `exchangedata` (when we moved to APFS) I think there are now too many downsides to atomic saving to make it the default :(
TextMate mailing list TextMate@lists.macromates.com https://lists.macromates.com/listinfo/textmate
*Attachments:*
- PastedImage.png
On 17 Apr 2020, at 4:19, Marc Wilson wrote:
I hope you don't actually make this change... atomic save is desirable, even if you end up losing some metadata.
Disabling atomic save is not motivated by Timothy’s problem, but with APFS atomic saving can only be done by writing a new file and then replace the old with the new via `rename`.
The problem with this is:
1. Extra care must be taken to preserve file meta data, i.e. must be copied from existing file to the new one we write. 2. If user does not have write permission to the directory containing the file, we simply can’t write the file, period. 3. Each save bumps the date of the containing directory: For tools observing file systems for changes¹, this means they will have to re-scan the directory to see what changed. 4. Since a new file is written, it gets a new inode and thereby breaks “references” to the file made via the inode. 5. Programs observing the file system via the kevent() API will be told that the file got deleted instead of written to (and they will have to check if a new file got written in its place).
Some of the above should not be visible to the user, as long as the software handles it properly, but at least item 2 and 3 are user visible and IMHO a regression compared to pre-APFS where we had `exchangedata` for atomic saves.
¹ This isn’t just real-time observing, but a build system may also end up doing more work because of this, if it supports globs to select input files or similar.
I’m not sure I believe that. Safe save is in fact one of the boasts of APFS. You ask for safe save, which causes the file system to clone the file and now you get copy-on-write automatically, which is far more efficient because only the changed blocks actually need to be written. When you’re done saving, the original is atomically swapped with the clone. m.
— matt neuburg, phd = http://www.apeth.net/matt/ pantes anthropoi tou eidenai oregontai phusei Programming iOS 13! http://shop.oreilly.com/product/0636920310075.do iOS 13 Fundamentals! http://shop.oreilly.com/product/0636920310068.do RubyFrontier! http://www.apeth.com/RubyFrontierDocs/default.html
On Apr 19, 2020, at 3:41 AM, Allan Odgaard mailinglist@textmate.org wrote:
On 17 Apr 2020, at 4:19, Marc Wilson wrote:
I hope you don't actually make this change... atomic save is desirable, even if you end up losing some metadata.
Disabling atomic save is not motivated by Timothy’s problem, but with APFS atomic saving can only be done by writing a new file and then replace the old with the new via rename.
The problem with this is:
Extra care must be taken to preserve file meta data, i.e. must be copied from existing file to the new one we write. If user does not have write permission to the directory containing the file, we simply can’t write the file, period. Each save bumps the date of the containing directory: For tools observing file systems for changes¹, this means they will have to re-scan the directory to see what changed. Since a new file is written, it gets a new inode and thereby breaks “references” to the file made via the inode. Programs observing the file system via the kevent() API will be told that the file got deleted instead of written to (and they will have to check if a new file got written in its place). Some of the above should not be visible to the user, as long as the software handles it properly, but at least item 2 and 3 are user visible and IMHO a regression compared to pre-APFS where we had exchangedata for atomic saves.
¹ This isn’t just real-time observing, but a build system may also end up doing more work because of this, if it supports globs to select input files or similar.
TextMate mailing list TextMate@lists.macromates.com https://lists.macromates.com/listinfo/textmate
On 19 Apr 2020, at 18:40, Matt Neuburg wrote:
I’m not sure I believe that. Safe save is in fact one of the boasts of APFS. You ask for safe save, which causes the file system to clone the file and now you get copy-on-write automatically, which is far more efficient because only the changed blocks actually need to be written. When you’re done saving, the original is atomically swapped with the clone. m.
Before APFS we had `exchangedata` which atomically swaps the data part of two files. Majority of applications derive no advantage from first cloning the file to be updated, they simply write out a new file and then swap it with the old one. In-place/partial update of a file during save is for applications where the file may be too big to hold in memory, like a disk image or a database backend, but require a specially crafted file format to support this.
After APFS we have to use `rename` for atomically overwriting the old file, but that has the disadvantages I listed in my email.
What you may have seen regarding atomic save and APFS is that Apple extended rename to also allow atomic renaming of directories even when the destination exist. This allows atomic save of bundles, which previously was not possible. But it is unrelated to my grief about APFS dropping support for `exchangedata`.
-
Allan Odgaard -
Marc Wilson -
Matt Neuburg -
Timothy Bates