Comment by astrange

Comment by astrange 2 days ago

> Yes this is why all competent libraries don't actually use string for path. They have their own path data type because it's actually a different data type.

What is different about it? I don't see any constraints here relevant to having a different type. Note that this thread has already confused the issue, because they said filename and you said path. A path can contain /, it just happens to mean something.

If you want a better abstraction to locations of files on disk, then you shouldn't use paths at all, since they break if the file gets moved.

const_cast 2 days ago

A string can contain characters a path cannot, depending on the operating system. So only some strings are valid paths.

Typically the way you do this is you have the constructor for path do the validation or you use a static path::fromString() function.

Also paths breaking when a file is moved is correct behavior sometimes. For example something like openFile() or moveFile() requires paths. Also path can be relative location.

Reply View 2 replies

astrange a day ago

> A string can contain characters a path cannot, depending on the operating system. So only some strings are valid paths.
Can it? If you want to open a file with invalid UTF8 in the name, then the path has to contain that.
And a path can contain the path separator - it's the filename that can't contain it.
> For example something like openFile() or moveFile() requires paths.
macOS has something called bookmark URLs that can contain things like inode numbers or addresses of network mounts. Apps use it to remember how to find recently opened files even if you've reorganized your disk or the mount has dropped off.
IIRC it does resolve to a path so it can use open() eventually, but you could imagine an alternative. Well, security issues aside.

Reply View | 1 reply
- adastra22 a day ago
  
  Rust allows null bytes in str. Most (all?) OS don't allow null bytes in filenames.
  
  Reply View | 0 replies