3

Is there any path open-source manipulation library which supports all of the following?

  • Unrestricted path lengths (i.e. the only restriction should be from the range of size_t, not arbitrary limitations like 256 characters)

  • Basic manipulations like canonicalization, the equivalent of basename, dirname, getting the file extension, getting the root, etc.

  • All valid Windows-style paths and file names, such as \Rooted, Dir/, C:\Dir/foo, File, \\Computer\Dir/File, \\.\C:, Foo\./.\Bar:ADS, or \\?\C:\Dir\Escaped:ADS:$DATA

    • I believe this should also cover POSIX-style paths, but if not, those should work too

I'd prefer C++, but C is also fine.

user541686
  • 205,094
  • 128
  • 528
  • 886
  • Well, definitely *not* boost.filesystem. It operates on very syntactic level and assumes that the path syntax is close to POSIX (e.g. extension is from the last dot to the end of the string)... – Yakov Galka Apr 01 '12 at 17:12
  • @ybungalobill: Indeed, Boost doesn't work. But for your particular example: *Isn't* the extension from the last dot to the end of the string? Or do you mean it's because it does not take into account paths like `\.foo`? – user541686 Apr 01 '12 at 17:16
  • 3
    I think you're asking for a bit too much if you don't want it to be windows-specific. For example, on most systems, overly long pathnames are not directly usable, period. You have to manually `chdir` or use `openat` multiple times to reach the target file. So even if the library had no limit, the pathnames it returned would be of little use. Also, on non-windows systems, files do not have canonical names (POSIX has hard links)... – R.. GitHub STOP HELPING ICE Apr 01 '12 at 17:20
  • 1
    @Mehrdad: Extension is not just last dot to end of string. For example, in `/home/me/.config/foo`, the extension is empty, not `.config/foo`. – R.. GitHub STOP HELPING ICE Apr 01 '12 at 17:21
  • 1
    @Mehrdad: No. This case it actually handles correctly (it's more complicated than what I said), but I mean because of things like `myfile.dat:stream1:$DATA`. Extension is `.dat`, not `.dat:stream1:$DATA`. The sad thing is that the author tries to push his library to the C++ standard. – Yakov Galka Apr 01 '12 at 17:22
  • @ybungalobill: Ah! Good point, thanks. :) – user541686 Apr 01 '12 at 17:23
  • 1
    @R.. : Windows (NTFS) systems no longer have canonical names, either. The best you can get is path renormalization (i.e. remove `\.\ ` and `\..\ `) – MSalters Apr 02 '12 at 10:01

2 Answers2

1

cwalk can do that. It's a small C path library.

Julius
  • 1,155
  • 9
  • 19
  • Upvoting, but it seems buggy... e.g. doesn't seem to handle NTFS streams or attributes when finding extensions... – user541686 Apr 11 '19 at 17:27
  • 1
    You are right, ADS isn't supported - however, is that even considered to be part of the path? Microsoft's [PathFindExtensionA](https://learn.microsoft.com/en-us/dotnet/api/system.io.path.getextension?view=netframework-4.8) and [Path.GetExtension](https://learn.microsoft.com/en-us/windows/desktop/api/shlwapi/nf-shlwapi-pathfindextensiona) don't seem to support that neither. It doesn't seem to be even [documented](https://learn.microsoft.com/en-us/dotnet/standard/io/file-path-formats)? – Julius Apr 11 '19 at 22:13
  • Microsoft's path APIs are known to be buggy. They don't even all support paths longer than `MAX_PATH` characters (until recent partial changes). They can get pretty weird too. Try `dir /b "C:\Windows:$I30:$INDEX_ALLOCATION\Notepad.exe"` in the command prompt – user541686 Apr 11 '19 at 22:14
0

Sounds like QDir and QFileInfo from Qt 4.

SigTerm
  • 26,089
  • 6
  • 66
  • 115