5 ms·

That's why the GP considers mutt broken. Drafts should be stored in ~/.mutt or /var, not /tmp. Files in /tmp should not be expected to survive a process.

rwmj 14y ago
This is exactly the point of the posting. Every program has to be examined for this problem, and it forces a complex decision about the storage hierarchy onto every programmer.
- saurik 14y ago
  That's like saying "RAM considered harmful", because every time a developer has to think "do I just store this in memory, or do I sync it to disk" "it forces a complex decision about the storage hierarchy": /tmp is simply RAM that has the API of a file; it used to be implemented using a horrible kludge with files on disk that were periodically deleted, but with tmpfs the dream became a reality.
  - prodigal_erik 14y ago
    RAM really is a harmful kludge. Neither Turing machines nor lambda calculus call for some of an algorithm's state to suddenly be obliterated. The only reason we put up with it is that disk and SSD are so much slower.
    - rwallace 14y ago
      Speed is not the only benefit of RAM. The internal data structures of most programs are gnarly messes of intertwined pointers, fragile, easily corrupted, hard to upgrade in place, almost impossible to fix when they break. The division between RAM and disk forces everything to be serialized at intervals to clean storage formats that can be reread for a fresh start. As a practical matter, that's a big enough benefit to justify enforcing the division at an API level even if disk were as fast as RAM.
      - prodigal_erik 14y ago
        The industry might produce less worthless crap without the crutch of "it's not quite unusable if you start over often enough".
    - TylerE 14y ago
      I've never understood the obsession with Turing machines. It's like basing one's core belief of what a car is off one of Da Vinci's crazy wind-up things.
    - cma 14y ago
      Ram is just state. Turing machines require a non-tape state machine mechanism. You could consider ram a part of that, 4 gigs corresponding to many many possible states.
      - saurik 14y ago
        Some people (I do not agree with this view) believe that applications should be universally persistent: so that they never "stop running" and never "lose data" even when the machine restarts or even if the programs are transferred between systems.
  - ta12121 14y ago
    /tmp is simply RAM that has the API of a file ...which used to behave, physically, as disk, and now behaves as RAM. If I'm doing large file manipulations that require temporary files larger than RAM where should I put them?
    - regularfry 14y ago
      /tmp. If it's tmpfs, it can expand into swap space.
      - ta12121 14y ago
        Swap is usually no bigger than two or three times your RAM. Disk in general is 10 to 100 times the size of your RAM.
        saurik 14y ago
        You should take all of the space you previously felt acceptable to provide /tmp and allocate it to swap space. The history and semantics of that folder and how it relates to RAM, especially on systems that could not implement swap space, actually make this make sense: if you upgrade to tmpfs from "periodic deletion of /tmp" and are not increasing the size of your swap partition accordingly, you are doing something wrong.
        regularfry 14y ago
        If you know you're going to need more space, you can just create a transient swapfile for the duration. Or use /var/cache, if you suspect you know better than tmpfs and the swap allocator.
    - luser001 14y ago
      According to the comments on the original article, that location is /var/tmp. Apparently it's some sort of convention/standard. First time I've heard about /var/tmp.
- gwillen 14y ago
  Do you consider distros that rm -rf /tmp on startup to be broken? If not, why not?
  - rwmj 14y ago
    Firstly Fedora (<= 17) doesn't do this. It has a tmpwatch cronjob which deletes files after 10 days (/tmp) and 30 days (/var/tmp). Secondly, no I don't think it's broken. But it doesn't in any way affect the fact that as a last resort I can reboot in single user mode and grab the precious mutt file before it gets deleted.
- mikeash 14y ago
  Every program has to be examined for this problem anyway, tempfs or otherwise, so I don't get the point.
- vidarh 14y ago
  Every program has had to be designed with this in mind for decades or be broken on any number of systems. This may be new behaviour for Fedora, but it's not a new thing on Linux, or for Unix-like systems in general. It's not just systems that delete on reboot, but also systems set up with cron-jobs to regularly wipe /tmp, or sysadmins that will (rightfully) see /tmp as something that can be wiped at pretty much time.
qznc 14y ago
I'd vote for ~/.cache

rwmj 14y ago

This is exactly the point of the posting. Every program has to be examined for this problem, and it forces a complex decision about the storage hierarchy onto every programmer.

saurik 14y ago
That's like saying "RAM considered harmful", because every time a developer has to think "do I just store this in memory, or do I sync it to disk" "it forces a complex decision about the storage hierarchy": /tmp is simply RAM that has the API of a file; it used to be implemented using a horrible kludge with files on disk that were periodically deleted, but with tmpfs the dream became a reality.
- prodigal_erik 14y ago
  RAM really is a harmful kludge. Neither Turing machines nor lambda calculus call for some of an algorithm's state to suddenly be obliterated. The only reason we put up with it is that disk and SSD are so much slower.
  - rwallace 14y ago
    Speed is not the only benefit of RAM. The internal data structures of most programs are gnarly messes of intertwined pointers, fragile, easily corrupted, hard to upgrade in place, almost impossible to fix when they break. The division between RAM and disk forces everything to be serialized at intervals to clean storage formats that can be reread for a fresh start. As a practical matter, that's a big enough benefit to justify enforcing the division at an API level even if disk were as fast as RAM.
    - prodigal_erik 14y ago
      The industry might produce less worthless crap without the crutch of "it's not quite unusable if you start over often enough".
  - TylerE 14y ago
    I've never understood the obsession with Turing machines. It's like basing one's core belief of what a car is off one of Da Vinci's crazy wind-up things.
  - cma 14y ago
    Ram is just state. Turing machines require a non-tape state machine mechanism. You could consider ram a part of that, 4 gigs corresponding to many many possible states.
    - saurik 14y ago
      Some people (I do not agree with this view) believe that applications should be universally persistent: so that they never "stop running" and never "lose data" even when the machine restarts or even if the programs are transferred between systems.
- ta12121 14y ago
  /tmp is simply RAM that has the API of a file ...which used to behave, physically, as disk, and now behaves as RAM. If I'm doing large file manipulations that require temporary files larger than RAM where should I put them?
  - regularfry 14y ago
    /tmp. If it's tmpfs, it can expand into swap space.
    - ta12121 14y ago
      Swap is usually no bigger than two or three times your RAM. Disk in general is 10 to 100 times the size of your RAM.
      - saurik 14y ago
        You should take all of the space you previously felt acceptable to provide /tmp and allocate it to swap space. The history and semantics of that folder and how it relates to RAM, especially on systems that could not implement swap space, actually make this make sense: if you upgrade to tmpfs from "periodic deletion of /tmp" and are not increasing the size of your swap partition accordingly, you are doing something wrong.
      - regularfry 14y ago
        If you know you're going to need more space, you can just create a transient swapfile for the duration. Or use /var/cache, if you suspect you know better than tmpfs and the swap allocator.
  - luser001 14y ago
    According to the comments on the original article, that location is /var/tmp. Apparently it's some sort of convention/standard. First time I've heard about /var/tmp.
gwillen 14y ago
Do you consider distros that rm -rf /tmp on startup to be broken? If not, why not?
- rwmj 14y ago
  Firstly Fedora (<= 17) doesn't do this. It has a tmpwatch cronjob which deletes files after 10 days (/tmp) and 30 days (/var/tmp). Secondly, no I don't think it's broken. But it doesn't in any way affect the fact that as a last resort I can reboot in single user mode and grab the precious mutt file before it gets deleted.
mikeash 14y ago
Every program has to be examined for this problem anyway, tempfs or otherwise, so I don't get the point.
vidarh 14y ago
Every program has had to be designed with this in mind for decades or be broken on any number of systems. This may be new behaviour for Fedora, but it's not a new thing on Linux, or for Unix-like systems in general. It's not just systems that delete on reboot, but also systems set up with cron-jobs to regularly wipe /tmp, or sysadmins that will (rightfully) see /tmp as something that can be wiped at pretty much time.

qznc 14y ago

I'd vote for ~/.cache