41–50 of 126 posts
Maybe we should do the same search on samba vulnerabilities have have him take a look in the mirror...
I'm sorry symlinks are a thorn in Jeremy's side, but they are useful from a user's perspective. Hard links don't fill the same need. You can't normally hard link directories. If a file has multiple links, finding them all normally requires scanning the entire file system, so deleting a file now becomes harder. A file with multiple links doesn't have an obvious canonical path. As an example of all these issues, I mana…
I'm sorry symlinks are a thorn in Jeremy's side, but they are useful from a user's perspective. Hard links don't fill the same need. You can't normally hard link directories. If a file has multiple links, finding them all normally requires scanning the entire file system, so deleting a file now becomes harder. A file with multiple links doesn't have an obvious canonical path. As an example of all these issues, I mana…
That's only to avoid loops, as far as I understand. Symlinks do allow loops, but require application programmers to handle them. So maybe we just need better APIs/API contracts around loops, rather than two types of links?
> If a file has multiple links, finding them all normally requires scanning the entire file system
Couldn't this pretty easily be solved at the file system level? Just store a back pointer from a file to each of its names.
The fact that it's possible to break symlinks very easily by deleting the pointed-to file (name) is a problem as well: Wouldn't application developers usually, or at least sometimes, want to know about the fact that they are about to break a link (or conversely, not deleting the final copy of a file and not just a reference to it)?
> So there are more reasons for symlinks than just "hard links are restricted to linking within the same filesystem"
I think this might be the only real (technical/historical) limitation. The rest could probably be worked around, but maybe having two distinct types of links, with these other binary decisions (allowing loops, making deletion explicit vs. a matter of referenc counting) being more or less arbitrarily bucketed into those two types based on what was easier to implement.
I'm sorry symlinks are a thorn in Jeremy's side, but they are useful from a user's perspective. Hard links don't fill the same need. You can't normally hard link directories. If a file has multiple links, finding them all normally requires scanning the entire file system, so deleting a file now becomes harder. A file with multiple links doesn't have an obvious canonical path. As an example of all these issues, I mana…
I take it an “alias” isn’t good in this case? An alias does follow a move of the original - usually.
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.
"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.
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.
The GC algorithms for hardlinked directories can be the same as for harlinked files: reference counting.
I'm sorry symlinks are a thorn in Jeremy's side, but they are useful from a user's perspective. Hard links don't fill the same need. You can't normally hard link directories. If a file has multiple links, finding them all normally requires scanning the entire file system, so deleting a file now becomes harder. A file with multiple links doesn't have an obvious canonical path. As an example of all these issues, I mana…
> You can't normally hard link directories. That's only to avoid loops, as far as I understand. Symlinks do allow loops, but require application programmers to handle them. So maybe we just need better APIs/API contracts around loops, rather than two types of links? > If a file has multiple links, finding them all normally requires scanning the entire file system Couldn't this pretty easily be solved at the file syst…
Earlier quoted context omitted.
I take it an “alias” isn’t good in this case? An alias does follow a move of the original - usually.
Interesting; how does that work under the hood?
Earlier quoted context omitted.
I take it an “alias” isn’t good in this case? An alias does follow a move of the original - usually.
Interesting; how does that work under the hood?
An alias is like a hybrid between a symbolic link and a hard link. Like a symbolic link, it's its own file type whose contents point to the original, but like a hard link it points to the original using its ID, not its path. So an alias works even if the original is moved, but it does not increase the original's link count and is its own distinct entity in the file system.