SetCreationTime, SetLastAccessTime, SetLastWriteTime Should not open a new stream to obtain a SafeFileHandle

[TrabacchinLuigi]

API Proposal

namespace System.IO
{
    public static class FileHandleExtensions
    {
        public static DateTime GetLastWriteTimeUtc(this SafeFileHandle fileHandle);
        public static void SetLastWriteTimeUtc(this SafeFileHandle fileHandle, DateTime time);
        public static DateTime GetLastAccessTimeUtc(this SafeFileHandle fileHandle);
        public static void SetLastAccessTimeUtc(this SafeFileHandle fileHandle, DateTime time);
        public static DateTime GetCreationTimeUtc(this SafeFileHandle fileHandle);
        public static void SetCreationTimeUtc(this SafeFileHandle fileHandle, DateTime time);
    }
}

Original post

I know that in many cases it is ok to do so, but we found ourself in the case where we need to set file times without closing the actual FileStream, and this is possible via Windows API.
To do so we had to write unsafe code which mimic the functionality of the existing functions.
(which include rewriting System.IO.__Error.WinIOError(), this is obviusly a bad thing, because we have to maintain code wich already exist)
This could be extremely more usable and maintainable if the framework exposed those methods as SafeFileHandle Method/ExtensionMethod.

My proposal is to leave those functions unaltered but move the actual implementation in an ipotetic function:
SafeFileHandle.SetFileTimesUtc(DateTime? creationTimeUtc, DateTime? lastAccessTimeUtc, DateTime? lastWriteTimeUtc) which should be public.

[kostadinmarinov]

Is there a plan this problem to be fixed soon?

[danmoseley]

@TrabacchinLuigi @kostadinmarinov next step would be for someone to format this as an API proposal as per the example linked in https://github.com/dotnet/corefx/blob/master/Documentation/project-docs/api-review-process.md

@JeremyKuhne do you have any feedback up front about this?

[JeremyKuhne]

I'm ok with us having this functionality, but I'd rather see this as extension methods on SafeFileHandle. This will allow hitting the functionality anytime you have a handle, not just with FileStream.

Something like:

namespace System.IO
{
    public static class FileHandleExtensions
    {
        public static DateTime GetLastWriteTimeUtc(this SafeFileHandle fileHandle);
        public static void SetLastWriteTimeUtc(this SafeFileHandle fileHandle, DateTime time);
        // etc...
    }
}

[kostadinmarinov]

Won't it be better and more consistent with the existing interface, if the methods are part of File class. This class already contains that functionality hidden as internal. We can move the body of the using into that public method and make the current one call it.

However, based on my copy-paste experience, I see one problem - __Error.WinIOError(errorCode, path) needs path and we don't have it. I am not so familiar with SafeFileHandle, but I don't see from where we can get it. I also see that it's not good to skip it as it will affect the exception messages. Instead we can change the SafeFileHandle parameter to be FileStream which contains the file path into Name property. It's just a suggestion on that problem.

[TrabacchinLuigi]

@kostadinmarinov I've tried to copy paste the actual implementation and i've end in the same situation where __Error.WinIoError(errorCode, path) need the path, IMHO a little refactor where the path is not needed and throw a simpler or dedicated exception and then FileStream catch it and re-throw shouldn't be that hard and so much slower ...
But Touching those parts of code seems like something very dangerous/scary.

I also like your solution where our extension methods target FileStream wich exposes SafeFileHandle and work with both ... we just need to make some methods from __Error to be public/accessible enough ... But i don't know where else SafeFileHandle are used and how ...

[TrabacchinLuigi]

I'm Already using SafeFileHandle ExtensionMethods with success, i just don't have the path in the exception message, but following the stack i'll get to more contextualized scope, so ... like i said, i wouldn't depend on the path...

[JeremyKuhne]

This is the full initial API shape we want to review.

namespace System.IO
{
    public static class FileHandleExtensions
    {
        public static DateTime GetLastWriteTimeUtc(this SafeFileHandle fileHandle);
        public static void SetLastWriteTimeUtc(this SafeFileHandle fileHandle, DateTime time);
        public static DateTime GetLastAccessTimeUtc(this SafeFileHandle fileHandle);
        public static void SetLastAccessTimeUtc(this SafeFileHandle fileHandle, DateTime time);
        public static DateTime GetCreationTimeUtc(this SafeFileHandle fileHandle);
        public static void SetCreationTimeUtc(this SafeFileHandle fileHandle, DateTime time);
    }
}

[terrajobst]

Video

• The scenario makes sense, but defining them as extension methods on SafeFileHandle seems odd
• It seems more logical to define them as overloads to the string based APIs on File.

namespace System.IO
{
    public static partial class File
    {
        public static DateTime GetCreationTime(SafeFileHandle fileHandle);
        public static DateTime GetCreationTimeUtc(SafeFileHandle fileHandle);
        public static DateTime GetLastAccessTime(SafeFileHandle fileHandle);
        public static DateTime GetLastAccessTimeUtc(SafeFileHandle fileHandle);
        public static DateTime GetLastWriteTime(SafeFileHandle fileHandle);
        public static DateTime GetLastWriteTimeUtc(SafeFileHandle fileHandle);

        public static void SetCreationTime(SafeFileHandle fileHandle, DateTime creationTime);
        public static void SetCreationTimeUtc(SafeFileHandle fileHandle, DateTime creatinTimeUtc);
        public static void SetLastAccessTime(SafeFileHandle fileHandle, DateTime lastAccessTime);
        public static void SetLastAccessTimeUtc(SafeFileHandle fileHandle, DateTime lastAccessTimeUtc);
        public static void SetLastWriteTime(SafeFileHandle fileHandle, DateTime lastWriteTime);
        public static void SetLastWriteTimeUtc(SafeFileHandle fileHandle, DateTime lastWriteTimeUtc);

        // Seems we should be adding support for these too.
        // If we can't make it work, dropping is fine.
        public static FileAttributes GetAttributes(SafeFileHandle fileHandle);
        public static void SetAttributes(SafeFileHandle fileHandle, FileAttributes fileAttributes);
    }
}

[danmoseley]

Any volunteers interested in adding these?

[fowl2]

The scenario makes sense, but defining them as extension methods on SafeFileHandle seems odd

They could be extension methods on SafeFileHandle in File for discoverability?

[fowl2]

There is an advantage to putting these on FileStream (perhaps in addition) beyond paths in exceptions and that is that we could avoid the SafeFileHandle property accessor which does this:

The SafeFileHandle property automatically flushes the stream and sets the current stream position to 0. This allows the file to be moved or the stream position to be reset by another stream using the SafeFileHandle returned by this property.