|
|
Subscribe / Log in / New account

XFS: the filesystem of the future?

XFS: the filesystem of the future?

Posted Mar 5, 2012 23:37 UTC (Mon) by dlang (guest, #313)
In reply to: XFS: the filesystem of the future? by nybble41
Parent article: XFS: the filesystem of the future?

> it's not guaranteed that there exists a directory on the same filesystem where you have permission to create a temporary file.

this sounds like a red hearing to me.

If you aren't allowed to create a new file in the directory of the file, are you sure you have permission to overwrite the file you are trying to modify?

as for the symlink/hardlink 'issue', in my sysadmin experience, more problems are caused by editors that modify files in place (not using temp files and renaming them) than by breaking links. Editors that break links when modifying a file are referred to as 'well behaved' in this area.


to post comments

XFS: the filesystem of the future?

Posted Mar 6, 2012 0:28 UTC (Tue) by nybble41 (subscriber, #55106) [Link]

> If you aren't allowed to create a new file in the directory of the file, are you sure you have permission to overwrite the file you are trying to modify?

These are orthogonal permissions. To overwrite the file you need write permission on the file. To create a new file in the same directory you need write permission on the directory. It's easily possible to have one without the other:

root# mkdir a
root# touch a/b
root# chown user a/b

user$ echo test > a/b # no error
user$ touch a/c
touch: cannot touch `a/c': Permission denied

> as for the symlink/hardlink 'issue', in my sysadmin experience, more problems are caused by editors that modify files in place (not using temp files and renaming them) than by breaking links.

Obviously that would remain an option. The point is that it should be an *option*, alongside the ability to atomically update a file in place. Symlinks are often used to add version control over configuration files (without putting the entire home / etc directory in the repository), while bind mounts are more often used with namespaces and chroot environments. Usually you want the latter to be read-only, but if the file is read/write it makes sense to allow it to be updated without breaking the link. (You can't just delete or rename over a bind target, either; it has to be unmounted.)


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds