21–30 of 126 posts
Also with hard link directories, you would want to be able "rmdir" non-empty directories, just to delete the link. But then you have the problem of reference loops, so how do you reclaim space reliably? You would need a garbage collection algorithm to find data not reachable by root.
"X is fundamentally broken" is a tired trope. To me, something is broken if it is no longer working as intended. It used to work, but now it does not - it is broken. If something works as intended, but its utility is limited, and it can be improved, it is not broken.
That “X − designed in the 70s when we had no idea of anything regarding computers − is fundamentally broken” isn't so surprising after all. In fact, computers are probably the only place in the entire technology landscape where we keep using almost unmodified stuff from the 70s and decided we cannot change it because there's too much things relying on it. I don't like breaking everything all the time more than anyone…
"X is fundamentally broken" is a tired trope. To me, something is broken if it is no longer working as intended. It used to work, but now it does not - it is broken. If something works as intended, but its utility is limited, and it can be improved, it is not broken.
Symlinks work as intended, but they cause a lot of unintended security vulnerabilities, i.e. they break lots of otherwise-functioning code. You can play with your words and redefine their meanings, but the vulnerabilities remain.
There is no otherwise! POSIX has symbolic links: if your software does not function with symbolic links, it does not function on POSIX.
Don't hard links suffer from the issue that because they're actually links to a specific file, not path pointers, that you can replace the target file thinking you have updated something in the system and instead have stale hard links lying around, referencing the older version when you intended to replace the older version for all users? I think that in a hypothetical world where symlinks worked like hard links, we'…
Earlier quoted context omitted.
> but they cause a lot of unintended security vulnerabilities No, bad coders on UNIX platforms do this. The code may be valid code, but if it's intending to support running on UNIX it should do it properly not assuming it's on a FAT32 filesystem in 2022. Or, even better, run the code you don't trust on fat32 filesystems, see how far that gets.
Don't victim blame. Do you really think that using open(), stat(), lstat() (!), realpath(), mkdir(), rename() etc etc etc is a sign of a bad coder? The problem is that the APIs set you up for unexpected failure, and even some of the provided workarounds to 'safely' handle symlinks don't do it well enough. In the case of symlinks, I think it's fair to blame the tools rather than the workman.
Example: wanna show 1M POI in browser on some small territory. Openmaps/googlemaps API allows that, no prob. Looks good, yeah? Sorry, doesn't work. Because 1M is too large to show and browser gets stuck.
The API do not prevent _all_ kinds of legshooting engineers invent.
There doesn't seem to be a way to batch together operations that involve walking through directories and symlinks to do something to a file. This seems to be a major source of complexity.
Could you elaborate? Seems like there’s a bunch of things that can’t be batched together on an ordinary file, without involving symlinks.
Another problem with hard links: you can not hard link a directory. It would make ".." ambiguous. Also with hard link directories, you would want to be able "rmdir" non-empty directories, just to delete the link. But then you have the problem of reference loops, so how do you reclaim space reliably? You would need a garbage collection algorithm to find data not reachable by root.
https://developer.apple.com/library/archive/documentation/Fi...
Earlier quoted context omitted.
I always thought Unix v7+ should have added some kind way to do atomic groups of syscalls, eg: begin_transaction (); lstat ("/path", ...); lstat ("/path/foo", ...); commit (); In Unix v7 mkdir was not a system call. It was a setuid program implemented using mknod + link. That was racy so the mkdir(2) system call was added. But it could have been solved more generally (and more elegantly) by adding transactions. It co…
Wasn't making userspace handle these kinds of things a big part of "worse is better"?
Another problem with hard links: you can not hard link a directory. It would make ".." ambiguous. Also with hard link directories, you would want to be able "rmdir" non-empty directories, just to delete the link. But then you have the problem of reference loops, so how do you reclaim space reliably? You would need a garbage collection algorithm to find data not reachable by root.
Whether directories can be hardlinked depends on the filesystem and OS. When macOS switched from HFS+ to APFS, one of the changes was that they dropped support for directory hardlinks. https://developer.apple.com/library/archive/documentation/Fi...
https://stackoverflow.com/questions/80875/what-is-the-unix-c...
The filesystem has to check for and disallow loops.
"X is fundamentally broken" is a tired trope. To me, something is broken if it is no longer working as intended. It used to work, but now it does not - it is broken. If something works as intended, but its utility is limited, and it can be improved, it is not broken.
When I'm exposed to a core OS feature I expect by default that it should not come with expected, critical security vulnerabilities. It is rational to expect a user to use the basic features of an OS and expect them not to cause severe issues. You can say it's not broken, and that's true in as much as they're still functional, but if by broken one means the larger question of "is this reliable and safe?" then I think the answer is pretty clear that symlinks are broken.