-
Notifications
You must be signed in to change notification settings - Fork 82
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
1601-01-01 times being sent to Utimens #35
Comments
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? |
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 |
I haven't got one yet. I'll see if I can make one.
Hmm that is an interesting idea. If it did it would be a go time 0 rather than an NTFS one so be |
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. |
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. |
It appears that sometimes Windows/WinFSP/cgofuse sends dates which are the epoch to rclone. These dates appear as 1601-01-01 00:00:00 plus or minus the timezone. These dates aren't being sent from rclone. This patch filters dates out before 1601-01-02 so rclone does not attempt to set them. See: https://forum.rclone.org/t/bug-corruption-of-modtime-via-vfs-layer/12204 See: https://forum.rclone.org/t/io-error-googleapi-error-403-insufficient-permission-insufficientpermissions/11372 See: winfsp/cgofuse#35
It appears that sometimes Windows/WinFSP/cgofuse sends dates which are the epoch to rclone. These dates appear as 1601-01-01 00:00:00 plus or minus the timezone. These dates aren't being sent from rclone. This patch filters dates out before 1601-01-02 so rclone does not attempt to set them. See: https://forum.rclone.org/t/bug-corruption-of-modtime-via-vfs-layer/12204 See: https://forum.rclone.org/t/io-error-googleapi-error-403-insufficient-permission-insufficientpermissions/11372 See: winfsp/cgofuse#35
An rclone user has discovered that sometimes Windows tries to set times on files which are 1601-01-01 via
Utimens
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
The text was updated successfully, but these errors were encountered: