4 ms·
Well I like the "workaround" that Microsoft proposes for a limitation of Windows that shouldn't really be to this day. UNIX resolved this decades ago: the file
by alerighi 3y ago
Well I like the "workaround" that Microsoft proposes for a limitation of Windows that shouldn't really be to this day.
UNIX resolved this decades ago: the filename is just a link to a structure on disk. You can delete a file even if it's used, since the file is there but you only delete the reference (filename pointing to the inode) that it has. Programs that have the file open can continue using it. When the file is no longer open by any programs the reference count is checked: if it's zero it means that the file can be safely deleted.
Not a difficult thing to implement, since they did it in the 70s... still Widnows doesn't get it.
- frankchn 3y agoIsn't that what the second line in the JavaScript snippet does: delete itself while the script is still in use (i.e. running?) In any case, I am not sure the Unix way is the best API design here. Sure, it does help in these scenarios, but now you can have hidden files lying around in the filesystem being used that I can't easily tell are even there.
- deleted 3y ago[deleted]
- deleted 3y ago[deleted]
- deleted 3y ago[deleted]
- sjsdaiuasgdia 3y agoThere's pros and cons both ways, it's an implementation decision. Under Linux, I have occasionally had the challenge of figuring out what process is holding open a large file that has been 'deleted'. This starts with recognizing that you're getting disparate values from different tools you might use to look at disk utilization. It's confusing as hell the first time you run into it without some established context as to why that might happen. On deletion of a file that is open by another process, Linux does not warn me about that. Windows will give me a clear error message that the file is open by another process. Linux chooses to let the problem sit because it might just take care of itself once the process ends, but that decision kinda sucks when your disk is full and you're scrambling to get some space back. Windows forces me to deal with the conflict right now. That adds work in some cases while avoiding the confusion and risk factors of multiple perspectives about a volume's utilization. It's not "Widnows (sic) doesn't get it". Windows made different choices. As another comment expressed, Windows has all it needs to do this at the FS layer, but chooses to use OS locks on top of that.