{"push_id":2607760173,"size":1,"distinct_size":1,"ref":"refs/heads/fssync-windows","head":"b8335559dd231eaff5707d4473c4d840f5ed4912","before":"39b0aed0776c5a96135560244b09a03336ae016d","commits":[{"sha":"b8335559dd231eaff5707d4473c4d840f5ed4912","author":{"name":"Ian Campbell","email":"a8db091655a7f47ecb9c39a2d278e9662e440dc0@docker.com"},"message":"diskwriter: pass wire/unix paths to callbacks.\n\nThe callbacks expect to operate on the wire form which is standardized on Unix\nformat.\n\nFor example `receiver.asyncDataFunc`, which is used as `AsyncDataCb` expects to\nuse the path as a key on a map lookup for an insertion done in the\n`PACKET_STAT` case of `receiver.run` using the wire form.\n\nThis matters on Windows where `filepath.FromSlash` will convert `/` into `\\`.\n\nOnly the `destPath` needs to be converted to the local form. I have confirmed\nthat all subsequent uses of `p` in `DiskWriter.Handle` are passing it to one of\nthe callbacks (either directly or via `DiskWriter.processChange` or\n`DiskWriter.requestAsyncFileData`, that latter just calls `processChange`) as a\nkey or for error messages.\n\nThe callbacks reachable in this way are `NotifyCallback`, `SyncDataCb` and\n`AsyncDataCb`, which are set to `recevier.notifyHashed`, `newWriteToFunc`\n(ignoring `nopWriteTo`) functions and `receiver.asyncDataFunc` respectively.\n\nThe `newWriteToFunc` is adjusted to cope with this change and\n`receive.asyncDataFunc` already expected a canonical form for path and does thr\ncorrect thing.\n\nThe `receiver.notifyHashed` callback is user-supplied via\n`RecieveOpt.NotifyHashed`. I have looked at the user in\n`github.com/moby/buildkit/session/filesync/diffcopy.go` which uses the\n`HandleChange` on a supplied `CacheUpdater`. One candidate for a supplied\nobject meeting this interface is\n`github.com/moby/buildkit/cache/contenthash/cacheContext`. The `HandleChange`\ncallback there does an immediate `filepath.ToSlash` which I think will need to\nbe removed when buildkit is updated, I've been unable to determine if the\nconsequences of not doing so are more serious than an artificial cache-bust.\n\nI've tested this (in the context of buildkit) with a Linux `sender` and Windows\n`receiver`, I've no capability to test the opposite direction.\n\nSigned-off-by: Ian Campbell <ijc@docker.com>","distinct":true,"url":"https://api.github.com/repos/ijc/fsutil/commits/b8335559dd231eaff5707d4473c4d840f5ed4912"}]}
{"actor":{"display_login":"ijc"}}