* DrGo <salah.mah...@gmail.com> [180806 18:37]: > There are situations where you need to check (and report back to the user) > for file existence no matter how you do that (using Stat or by attempting > to open or create it).
I agree completely. However, doesn't os.Stat do what you want here simply and portably? If not, what would you like from such a function? Note that path canonicalization is orthogonal to this. > There are several issues with the approach you described, which is > essentially what fileapth.Abs() does, some are discussed here > https://github.com/golang/go/issues/17084 > and here <https://www.baeldung.com/java-path> The discussion in the first appears to come to the conclusion that in some cases it is not possible to get a unique canonical name. Two different Windows UNC or network paths can point to the same file in a way that it is not possible for the local machine to be able to determine this. The same is true for remotely mounted file systems on Linux (e.g. NFS or CIFS mounts). Hard links (both Windows and Linux) are problematic at best. You could arbitrarily say that the alphabetically first name was the canonical one (or use other criteria), but in order to determine all possible names still requires (worst case) traversing the entire file system directory structure; from a performance POV, I would not want to do this. The second link really just describes Java's getCanonicalPath and related functions, but doesn't really say much else. The Java doc for this claims to return a "unique" name, but says nothing about how that is done for either of the two cases described above. This is not the only place where the Java documentation left me wondering how it handled edge conditions. A simple test shows that it fails to recognize that a single file with two hard links in the same directory are the same file. This is not any different from failing to replace symbolic links. So the real question is what are you trying to accomplish with a canonicalization function? Are you simply looking for Abs(EvalSymlinks(path)) except with a guarantee in the documentation for EvalSymlinks that says both the 8.3 and long file names for the same file will give identical results? What transformations do you want it to perform and what transformations are acceptable to ignore? * DrGo <salah.mah...@gmail.com> [180806 02:00]: > Thanks, > filepath.Abs does some of what I want, but as far as I could tell, it does > not handle resolving relative paths Can you give an example of how it does not handle relative paths the way you would like? I'm having trouble identifying what you believe are the shortcomings of the simple solutions provided in this thread and the link you gave above. ...Marvin -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
