Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Still, it looks like the right thing to do is let the filesystem do the filesystem's job. The filesystem should be normalizing unicode and enforceing the case-insensitivity and whatnot, but just the filesystem. Wrappers around it like whatever Nextcloud is doing should be treating the filenames as a dumb pile of bytes.


I'm not sure this problem even has a "right" solution.

> Wrappers around it like whatever Nextcloud is doing should be treating the filenames as a dumb pile of bytes.

What do you do when the input isn't a dumb pile of bytes, but actual text? (Like from a text box the user typed into?)


Maintain a table that maps the original file name to random-generated one that doesn't hit these gotchas.


I'm afraid I don't follow. Who maintains this table and who consumes it? What if they're different entities? How do you prevent it from going out of sync with the file system when the user renames a file? Are you inventing your own file system here? How do you deal with existing file systems?


I assumed that you have a system where file management/synchronization happens strictly through a web interface, and files are not changed or renamed outside this system's knowledge. Under these preconditions, having such a mapping table frees the users from having to abide whatever restrictions the underlying file system places on valid file names.


Oh I was talking about the general case from a programming standpoint. What do you do on a typical local filesystem?

The point I'm trying to get at being, you need to worry about the representation at multiple layers, not just at the bottom FS layer.


And place the files in chunks, and... Wait I think we're getting close to reinventing block storage again ;)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: