Skip to content

Should os.ModeCharDevice be taken into account? #139

@thaJeztah

Description

@thaJeztah

Relates to moby/moby#38758 / moby/moby#38404 (comment) / golang/go@a2a3dd0

Due to a change in Go 1.12, some file modes are no longer being returned as os. ModeDevice, but as os.ModeCharDevice. This caused pulling images to break on docker (moby/moby#38404 (comment)).

I'm not very familiar with this repository, but a quick search showed some similar uses in this package, so I suspect some of those will have to be updated accordingly.

continuity/fs/copy.go

Lines 137 to 140 in 004b464

case (fi.Mode() & os.ModeDevice) == os.ModeDevice:
if err := copyDevice(target, fi); err != nil {
return errors.Wrapf(err, "failed to create device")
}

continuity/resource.go

Lines 552 to 553 in c2ac4ec

case base.Mode()&os.ModeDevice != 0:
return newDevice(*base, b.Path, b.Major, b.Minor)

continuity/resource.go

Lines 434 to 437 in c2ac4ec

func newDevice(base resource, paths []string, major, minor uint64) (Device, error) {
if base.Mode()&os.ModeDevice == 0 {
return nil, fmt.Errorf("not a device")
}

continuity/context.go

Lines 501 to 502 in c2ac4ec

} else if (fi.Mode() & os.ModeDevice) == 0 {
return fmt.Errorf("%q should be a device, but is not", resource.Path())

if fi.Mode()&os.ModeDevice != 0 {

if mode&os.ModeDevice != 0 {

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions