[lkml]   [2011]   [Jun]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH -v2] vfs: make unlink() return ENOENT in preference to EROFS
    07.06.2011 02:30, Al Viro wrote:
    > On Mon, Jun 06, 2011 at 04:58:13PM -0400, Theodore Ts'o wrote:
    >> If user space attempts to unlink a non-existent file, and the file
    >> system is mounted read-only, return ENOENT instead of EROFS. Either
    >> error code is arguably valid/correct, but ENOENT is a more specific
    >> error message.
    > Umm... I can live with that. What about rmdir(2)? We have similar situation
    > there as well. If we care about one, why not the other?

    I think both should be fixed.

    > Mind you, I'm not at all convinced that it matters enough to bother, but
    > yes, ENOENT is a bit more specific (and likelier to be handled by luserland
    > code).

    The problem which triggered the initial thread and Ted's patch was me
    trying to commit some changes from read-only /etc into git tree. This
    works for everything but deletes, since `git rm' barfs when unlink for
    a non-existing file returns EROFS. rm(1) has been patched especially
    for this case at about kernel 2.6.32 time, as shown in comments at ,
    but git has not (yet), and I suspect git isn't the only leftover, there
    are other applications to patch still, if the kernel will continue to
    return EROFS.

    Besides, POSIX says (

    The directory entry to be unlinked
    is part of a read-only file system

    so it clearly states that the entry should exists for EROFS, ie, to
    be _part_ of the filesystem.



     \ /
      Last update: 2011-06-07 00:51    [W:0.021 / U:9.956 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site