1601-01-01 times being sent to Utimens

[Nick Craig-Wood]

An rclone user has discovered that sometimes Windows tries to set times on files which are 1601-01-01 via Utimens

2019/08/22 18:57:39 DEBUG : /rclonereadme - Shortcut.lnk: Utimens: tmsp=[{Sec:-11644473600 Nsec:-100} {Sec:-11644473600 Nsec:-100}]

According to my reading, that time is the epoch on NTFS so that is effectively a zero time value.

Should cgofuse (or maybe WinFSP) be filtering these out? Or is it rclone's job to work out that these are invalid?

I'm not sure of the circumstances which these come through yet.

Any help much appreciated - thanks :-)

For background see: https://forum.rclone.org/t/io-error-googleapi-error-403-insufficient-permission-insufficientpermissions/11372/3

[Bill Zissimopoulos]

I suspect that if this is a problem, it is likely a problem on the FUSE layer of WinFsp.

Relevant code is here:

https://github.com/billziss-gh/winfsp/blob/v1.5B2/src/dll/fuse/fuse_intf.c#L1384-L1469

Is there an easy repro?

[Bill Zissimopoulos]

This code from the WinFsp FUSE layer:

        if (0 == LastAccessTime || 0 == LastWriteTime)
        {
            Result = fsp_fuse_intf_GetFileInfoEx(FileSystem, filedesc->PosixPath,
                FUSE_FILE_INFO(filedesc->IsDirectory, &fi),
                &Uid, &Gid, &Mode, &FileInfoBuf);
            if (!NT_SUCCESS(Result))
                return Result;

            if (0 == LastAccessTime)
                LastAccessTime = FileInfoBuf.LastAccessTime;
            if (0 == LastWriteTime)
                LastWriteTime = FileInfoBuf.LastWriteTime;
        }

Issues a getattr to the file system if any of the times passed are 0 (which instructs the file system to not modify those times). Is it possible that rclone responds with a 0 time in a getattr call?

[Nick Craig-Wood]

Is there an easy repro?

I haven't got one yet. I'll see if I can make one.

Is it possible that rclone responds with a 0 time in a getattr call?

Hmm that is an interesting idea. If it did it would be a go time 0 rather than an NTFS one so be January 1, year 1, 00:00:00 UTC. Looking at the code I don't think it can, but there might be some corner case I can't see!

[Nick Craig-Wood]

What it looks like is that the user has some files which don't have modification times.

I think WinFSP is doing its best with these files passing through the date as the Epoch.

So I'm going to close this as I don't think it can be fixed in WinFSP.

[Bill Zissimopoulos]

Thanks for the explanation. Let me know if you eventually believe that there is a more sensible solution for this in WinFsp and/or cgofuse.