3 ms·

You don't? Those are either free space, or held by handle by a running process, so you just leave them be and assume they will be released sooner or later. Wors

You don't? Those are either free space, or held by handle by a running process, so you just leave them be and assume they will be released sooner or later. Worst case you defragment on boot. https://unix.stackexchange.com/questions/68523/find-and-remove-large-files-that-are-open-but-have-been-deleted https://unix.stackexchange.com/questions/68523/find-and-remo... This is how it works on UNIX. Generally better then apps randomly failing because a file(name) is held open somewhere by something.

dataflow 3y ago
> You don't? Those are either free space, or held by handle by a running process, so you just leave them be and assume they will be released sooner or later. Well that's what I was getting at, it would suck to not be able to move around file blocks just because a process is using the file. That "sooner or later" might well be "until the next reboot". The current strategy makes it possible to live-shrink and live-defragment volumes on Windows - ironically, saving you a reboot in those cases compared to Linux. But actually, maybe not - see the edit in my original comment.
- fodkodrasz 3y ago
  I'm yet to want to defrag my computer and worrying about still open deleted files. I face builds failing because I have a terminal open in a build output directory or a textfile in an editor open is far more often, and annoys me more. (or being unable to replace a running service binary of a service being developed/tested, needing to stop the service, replace it, and start again. Or failing log rotations because a logfile is open in a Notepad. Or...) Also see my link for a solution on unix, where you can indeed fix this problem, or simply kill the process holding the file. I didn't need to defrag my computer in the last 20 years, neither on Linux, nor on Windows, but hey, it makes me happy that my daily work is hindered for this hypothetical possibility. (which could and is solved in other OSs with appropriate APIs for the job) Also the original post is about Windows installers... don't get me started on the topic (or windows services), please.
  - dataflow 3y ago
    I wasn't just talking about defragging. I was also talking about live volume shrinking. > Also see my link for a solution on unix, where you can indeed fix this problem Looping through every FD of every process just to find ones that reside in your volume of interest is... a hack. From the user's perspective, sure, it might work when you don't have something better. From the vendor's perspective, it's not the kind of solution you design for & tell people to use. In fact, I think that "solution" is buggy. Every time you open a an object that doesn't belong to you, you extend its lifetime. I think that can break stuff. Like imagine you open a socket in some server, then the server closes it. Then that server (or another one) starts up again and tries to bind to the same port. But you're still holding it open, so now it can't do that, and it errors out. > or simply kill the process holding the file. That process might be a long-running process you want to keep running, or a system process. At that point you might as well not support live volume shrinking or defrags, and just tell people to reboot. > Also the original post is about Windows installers... don't get me started on the topic (or windows services), please. This seems pretty irrelevant to the point? It's not like they would design the kernel to say "we'll let you do this if you promise you're an installer". > I face builds failing because I have a terminal open in a build output directory or a textfile in an editor open is far more often [...] Yes, I agree it's frustrating. But have you considered the UX issues here? The user has C:\blah\foo.txt open, and you delete C:\blah\. The user saves foo.txt happily, then reopens it and... their data is gone? You: "Yeah, because I deleted it." User: "Wait but I was still using it??!"
    - fodkodrasz 3y ago
      I have considered it. Never had any serious problem about it during 15 years of desktop linux use as a developer machine. Grandma would not have more problems than unplugging the pendrive where the file was opened from, and trying to save it, for example... Modern operating systems have far worse and more user hostile patterns. And for the live volume shrinking: the kernel can solve this problem, it there is a need for this, there is no need for this invariant for this feature, as it is not only possible to do it via the same APIs offered for ordinary basic file manipulation gruntwork. On unix basically a filename is disassociated from the inode, but afaik the inode holding the blocklist still exists, will be cleaned up later, thus it can be updated if its blocks are moved under the high level filesystem APIs. You just made a strawman you are sticking to.
- yrro 3y ago
  'Sooner or later' means 'until the file is no longer open'.
  - dataflow 3y ago
    Yes? And that might not happen until you log off or shut down the OS.
    - yrro 3y ago
      But it doesn't have to. Space is freed up deterministically, not "sooner or later".
      - dataflow 3y ago
        What? Space can't be freed up while the file is in use. The process is using the file, the data needs to be there...

dataflow 3y ago

> You don't? Those are either free space, or held by handle by a running process, so you just leave them be and assume they will be released sooner or later. Well that's what I was getting at, it would suck to not be able to move around file blocks just because a process is using the file. That "sooner or later" might well be "until the next reboot". The current strategy makes it possible to live-shrink and live-defragment volumes on Windows - ironically, saving you a reboot in those cases compared to Linux. But actually, maybe not - see the edit in my original comment.

fodkodrasz 3y ago
I'm yet to want to defrag my computer and worrying about still open deleted files. I face builds failing because I have a terminal open in a build output directory or a textfile in an editor open is far more often, and annoys me more. (or being unable to replace a running service binary of a service being developed/tested, needing to stop the service, replace it, and start again. Or failing log rotations because a logfile is open in a Notepad. Or...) Also see my link for a solution on unix, where you can indeed fix this problem, or simply kill the process holding the file. I didn't need to defrag my computer in the last 20 years, neither on Linux, nor on Windows, but hey, it makes me happy that my daily work is hindered for this hypothetical possibility. (which could and is solved in other OSs with appropriate APIs for the job) Also the original post is about Windows installers... don't get me started on the topic (or windows services), please.
- dataflow 3y ago
  I wasn't just talking about defragging. I was also talking about live volume shrinking. > Also see my link for a solution on unix, where you can indeed fix this problem Looping through every FD of every process just to find ones that reside in your volume of interest is... a hack. From the user's perspective, sure, it might work when you don't have something better. From the vendor's perspective, it's not the kind of solution you design for & tell people to use. In fact, I think that "solution" is buggy. Every time you open a an object that doesn't belong to you, you extend its lifetime. I think that can break stuff. Like imagine you open a socket in some server, then the server closes it. Then that server (or another one) starts up again and tries to bind to the same port. But you're still holding it open, so now it can't do that, and it errors out. > or simply kill the process holding the file. That process might be a long-running process you want to keep running, or a system process. At that point you might as well not support live volume shrinking or defrags, and just tell people to reboot. > Also the original post is about Windows installers... don't get me started on the topic (or windows services), please. This seems pretty irrelevant to the point? It's not like they would design the kernel to say "we'll let you do this if you promise you're an installer". > I face builds failing because I have a terminal open in a build output directory or a textfile in an editor open is far more often [...] Yes, I agree it's frustrating. But have you considered the UX issues here? The user has C:\blah\foo.txt open, and you delete C:\blah\. The user saves foo.txt happily, then reopens it and... their data is gone? You: "Yeah, because I deleted it." User: "Wait but I was still using it??!"
  - fodkodrasz 3y ago
    I have considered it. Never had any serious problem about it during 15 years of desktop linux use as a developer machine. Grandma would not have more problems than unplugging the pendrive where the file was opened from, and trying to save it, for example... Modern operating systems have far worse and more user hostile patterns. And for the live volume shrinking: the kernel can solve this problem, it there is a need for this, there is no need for this invariant for this feature, as it is not only possible to do it via the same APIs offered for ordinary basic file manipulation gruntwork. On unix basically a filename is disassociated from the inode, but afaik the inode holding the blocklist still exists, will be cleaned up later, thus it can be updated if its blocks are moved under the high level filesystem APIs. You just made a strawman you are sticking to.
yrro 3y ago
'Sooner or later' means 'until the file is no longer open'.
- dataflow 3y ago
  Yes? And that might not happen until you log off or shut down the OS.
  - yrro 3y ago
    But it doesn't have to. Space is freed up deterministically, not "sooner or later".
    - dataflow 3y ago
      What? Space can't be freed up while the file is in use. The process is using the file, the data needs to be there...