[ruby-core:44778] [ruby-trunk - Feature #4052] File.lutime Patch

Issue #4052 has been updated by akr (Akira Tanaka).

Description updated

I found that File.lutimes can be used in fileutils.rb.

Recently I fixed copy_metadata method in fileutils.rb.
It copies metadata (atime, mtime, owner, group and mode) but it doesn't care symbolic links.

I changed the method to support symbolic links.
However atime and mtime could not be copied because we don't have File.lutime.
----------------------------------------
Feature #4052: File.lutime Patch
https://bugs.ruby-lang.org/issues/4052#change-26347

Author: runpaint (Run Paint Run Run)
Status: Assigned
Priority: Normal
Assignee: matz (Yukihiro Matsumoto)
Category: core
Target version: 


=begin
 This patch implements File.lutime, which behaves as File.utime except if given a symlink it acts upon the link itself rather than the referent. The naming convention follows that of the other singleton methods of File which treat symlinks specially. This functionality could be implemented by a gem, but given we already define File.lchmod, File.lchown, and File.lstat, it is inconsistent not to also define File.lutime.
 
 This functionality is provided by either lutimes(3), or utimensat(2) with the AT_SYMLINK_NOFOLLOW flag. The latter is standardised by POSIX <http://goo.gl/38pHx>
 
 Platform support is as follows:
 * FreeBSD - Has lutimes(2) since version 3. <http://goo.gl/9OWRF>
 * Mac OS - Has lutimes since at least version 10.5. <http://goo.gl/pSvM1>
 * OpenBSD - Appears to lack both APIs.
 * Linux - Supported lutimes(3) and utimensat(2) since version 2.6.22. (lutimes() is just a wrapper for utimensat()). <http://goo.gl/p29ja>
 * Windows - No support.
 
 For the status of esoteric platforms, consult http://goo.gl/Bf4Qm and http://goo.gl/7h6cj .
 
 On platforms that don't support either function, File.lutime raises a NotImplementedError.
 
 The portability logic is a bit hairy, so I'll summarise:
 
 1 - File.lutime requires either lutimes() to be defined or both utimensat() and AT_SYMLINK_NOFOLLOW. I'm not aware of a practical case where utimensat() would be defined without AT_SYMLINK_NOFOLLOW. Further, File.lutime requires utimes(). This isn't strictly necessary, but simplifies the logic: it seems most unlikely that a platform would support either lutimes() or utimensat() without also supporting utimes().
 2 - Like File.utime, we prefer to use utimensat() as it provides better resolution than utimes(). 
 3 - If utimensat(..., AT_SYMLINK_NOFOLLOW) sets errno to ENOSYS, there are two possibilities: either the platform doesn't support the system call, or, like Linux 2.6.22 (<http://goo.gl/Bf4Qm>), utimensat() is defined but raises ENOSYS when given this flag. If utimensat() gives ENOSYS when it wasn't passed AT_SYMLINK_NOFOLLOW, we assume the syscall really doesn't exist, and bypass it for all future invocations of File.utime and File.lutime. If utimensat() gives ENOSYS when passed AT_SYMLINK_NOFOLLOW, or AT_SYMLINK_NOFOLLOW_ isn't defined, we bypass utimensat() for all future File.lutime invocations, but still consider it for future File.utime invocations.
 4 - If we can't use utimensat() we fall back on lutimes().
 5 - If a platform defines utimensat() and AT_SYMLINK_NOFOLLOW, but the former gives ENOSYS when passed the latter, we also fall back on lutimes(). However, if the platform doesn't define lutimes(), we raise NotImplementedError.
 
 Tests are attached for File.utime when given a symlink and File.lutime.
=end



-- 
http://bugs.ruby-lang.org/