Skip to content
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

os: let FileInfo type also contain the full path, not just basename #32300

Closed
rogierlommers opened this issue May 29, 2019 · 6 comments
Closed

os: let FileInfo type also contain the full path, not just basename #32300

rogierlommers opened this issue May 29, 2019 · 6 comments

Comments

@rogierlommers
Copy link

@rogierlommers rogierlommers commented May 29, 2019

What version of Go are you using (go version)?

$ go version
go version go1.12.4 darwin/amd64

Does this issue reproduce with the latest release?

yes

What did you do?

I often use the FileInfo type to work with files. The file struct now contains the following:

type FileInfo interface {
	Name() string       // base name of the file
	Size() int64        // length in bytes for regular files; system-dependent for others
	Mode() FileMode     // file mode bits
	ModTime() time.Time // modification time
	IsDir() bool        // abbreviation for Mode().IsDir()
	Sys() interface{}   // underlying data source (can return nil)
}

Now I was wondering: why doesn't it contain the full path to the file? I often pass around a File to functions, but I see myself always reconstruct the full path, which -in my opinion- could also be part of the File itself.

#just wondering

@mvdan

This comment has been minimized.

Copy link
Member

@mvdan mvdan commented May 29, 2019

You showed the FileInfo interface, though. File does contain the original path that was opened:

// Name returns the name of the file as presented to Open.
func (f *File) Name() string
@rogierlommers

This comment has been minimized.

Copy link
Author

@rogierlommers rogierlommers commented May 29, 2019

Sorry, my bad. To give you an example of what I usually do:

files, _ := ioutil.ReadDir(splittedLocation)
for _, file := range files {
  if err := processFile(file); err != nil {
    // handle err
  }
}

And then, in the processFile function, I need the full file path to read the file. But then it's not available in the fileInfo struct.

@mvdan

This comment has been minimized.

Copy link
Member

@mvdan mvdan commented May 29, 2019

Right; then the issue should be about FileInfo to be clear.

In that case I'd simply pass the directory path along with each file. Then you can join the path with the basename easily. I'm not sure that this is a big issue.

@rogierlommers rogierlommers changed the title Let File type also contain the full path, not just basename Let FileInfo type also contain the full path, not just basename May 29, 2019
@rogierlommers

This comment has been minimized.

Copy link
Author

@rogierlommers rogierlommers commented May 29, 2019

Right; then the issue should be about FileInfo to be clear.

In that case I'd simply pass the directory path along with each file. Then you can join the path with the basename easily. I'm not sure that this is a big issue.

This indeed can be a workaround, but I don't see why the full filepath couldn't be part of the fileInfo struct.

@julieqiu julieqiu changed the title Let FileInfo type also contain the full path, not just basename os: let FileInfo type also contain the full path, not just basename May 29, 2019
@julieqiu

This comment has been minimized.

Copy link

@julieqiu julieqiu commented May 29, 2019

@bradfitz

This comment has been minimized.

Copy link
Contributor

@bradfitz bradfitz commented May 29, 2019

a) for go1compat reasons, we can't extend the FileInfo interface, even if we wanted to.

b) a full path name isn't always available/known/unique. There could be multiple paths to a file, and only some paths that are accessible to the current user. From the point of view of Readdir, it only gets the base names from the operating systems, so that's all it can return anyway. The *os.File only returns the "full" name if you opened it with a full name, and it just returns the exact string you opened with, which might be relative.

Closing, because there's nothing we can do here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants
You can’t perform that action at this time.