back
2 comments
Which, until recently, was losing file metadata, like extended attributes (in very old tmpfs versions also the timestamps could have been truncated).

Whenever exact file copies are desired, they must not pass through /tmp or through any other place where tmpfs is mounted, unless it is checked that the tmpfs version is new enough to preserve file metadata.

(In multi-user computers, it was usual to copy a file through /tmp for copies between users, because that might have been the only place where both users had access.)

Older versions of tmpfs did not support any extended attributes, then only certain system attributes were preserved, while all user attributes were deleted. Only one year or two ago tmpfs has been enhanced to preserve most extended attributes, with some size constraints. Many older systems still have tmpfs versions that lose the extended attributes.

Oh heck, good point. I forgot about that in my criticism, extended attributes. If you've gone through the effort of actually using SELinux, this could undo it... at least to the point of requiring 'restorecon' to reapply the context policy on deleted-then-restored files

So the trash bin leaves grime on things, great.

Self-clearing insecure recycle bin, but it's memory safe!!!
And if you delete too much the trash folder on tmpfs will fill up to half your available memory. With how terrible linux is with swap, unintentionally deleting a lot of data while doing something memory-intensive may well cause your system to slow to a crawl, forcing you to either sit it out or reboot and lose your recycle bin
Don't forget 'systemd-oomd' who may try to help. Depending on the configuration of your distribution/desktop environment, there's a non-zero chance your whole DE gets whacked. I generally am a fan of 'systemd', but the collection of parts require attention. cgroups and such

Absolutely none of this is a concern for this project, though. I just find this-then-that stuff funny