5 ms·

> If you are allowing user to mess with your files […] That's the problem. They shouldn't be your files, they should be the user's files.

by kps 5y ago

theamk 5y ago
As a software author, they are "my files" as long as I am responsible for them. Think like a school teacher saying "my class" -- it does not mean the kids belong to teacher, but it does mean that as long as teacher is responsible for them, the kids should be following teacher's instructions. The same goes with the files -- sure, they belong to user, but as long as you want to process it in the program, you need to follow program's rules. How complex and onerous those rules are depends entirely on the program. For example: - Text editor like emacs can handle pretty much any file you throw at it -- but OpenOffice will fail with "file damaged" error if you just change 1 byte in the file header - Many programs require filenames to have certain suffix - Some programs require files to live in designated "projects" dir - A lot of programs have some sort of internal database and will fail if user edits it in a non-trivial way. - Some programs require you to do special manual actions anytime you rename the file using third-party file managers (for example, git needs "git add"/"git rm") Let's not pretend that allowing arbitrary file renames is some sort of ideological standpoint which separates "user files" from "non-user's files". Every program requires something from user to work, and "do not allow arbitrary filenames" is just one point on this spectrum. OpenSSL does not impinge on user freedom just because it requires a very rigid naming structure in /etc/ssl/cert.
- ghoward 5y ago
  > As a software author, they are "my files" as long as I am responsible for them. As a software author, you are only responsible for those files insofar as the user allows you to be. The user still owns those files and can do whatever they want with them. If they have damaged the files your software uses, that's on them, not you; you are not responsible for that, unless it was your software that did it. Also, it should be pretty simple for a piece of software to tell the user why it can't open a file it needs to open, including a damaged header, a wrong suffix or filename, or a file not being in the correct directory. If the user caused the problem, telling them the problem should make it easy for them to fix it. In addition to that, if software does not have flexibility in where they put files (such as using environment variables), I would argue that that rigidity does, in fact, impinge on user freedom.
  - auggierose 5y ago
    > If the user caused the problem, telling them the problem should make it easy for them to fix it. Ever shipped consumer software?
    - ghoward 5y ago
      What's your point? Consumers still own their files. Claiming that consumer-oriented software should "own" the files created by the software is the same as claiming that consumers are too stupid for their own good. Personally, I would not want to use software made by a company that believes that.
      - auggierose 5y ago
        Apparently not. I am not against files, actually, I am a big proponent of files. But your statement I quoted is just naive.
        ghoward 5y ago
        No, I have not shipped any, but I've used plenty, and I hate how such software treats users. Also, I said that it should make it easy, which I understood to mean that there will still be some people for whom it won't help because they simply don't know how or what they did that destroyed their files.

> If you are allowing user to mess with your files […] That's the problem. They shouldn't be your files, they should be the user's files.

by kps 5y ago

> If you are allowing user to mess with your files […] That's the problem. They shouldn't be your files, they should be the user's files.

theamk 5y ago

As a software author, they are "my files" as long as I am responsible for them. Think like a school teacher saying "my class" -- it does not mean the kids belong to teacher, but it does mean that as long as teacher is responsible for them, the kids should be following teacher's instructions. The same goes with the files -- sure, they belong to user, but as long as you want to process it in the program, you need to follow program's rules. How complex and onerous those rules are depends entirely on the program. For example: - Text editor like emacs can handle pretty much any file you throw at it -- but OpenOffice will fail with "file damaged" error if you just change 1 byte in the file header - Many programs require filenames to have certain suffix - Some programs require files to live in designated "projects" dir - A lot of programs have some sort of internal database and will fail if user edits it in a non-trivial way. - Some programs require you to do special manual actions anytime you rename the file using third-party file managers (for example, git needs "git add"/"git rm") Let's not pretend that allowing arbitrary file renames is some sort of ideological standpoint which separates "user files" from "non-user's files". Every program requires something from user to work, and "do not allow arbitrary filenames" is just one point on this spectrum. OpenSSL does not impinge on user freedom just because it requires a very rigid naming structure in /etc/ssl/cert.

ghoward 5y ago
> As a software author, they are "my files" as long as I am responsible for them. As a software author, you are only responsible for those files insofar as the user allows you to be. The user still owns those files and can do whatever they want with them. If they have damaged the files your software uses, that's on them, not you; you are not responsible for that, unless it was your software that did it. Also, it should be pretty simple for a piece of software to tell the user why it can't open a file it needs to open, including a damaged header, a wrong suffix or filename, or a file not being in the correct directory. If the user caused the problem, telling them the problem should make it easy for them to fix it. In addition to that, if software does not have flexibility in where they put files (such as using environment variables), I would argue that that rigidity does, in fact, impinge on user freedom.
- auggierose 5y ago
  > If the user caused the problem, telling them the problem should make it easy for them to fix it. Ever shipped consumer software?
  - ghoward 5y ago
    What's your point? Consumers still own their files. Claiming that consumer-oriented software should "own" the files created by the software is the same as claiming that consumers are too stupid for their own good. Personally, I would not want to use software made by a company that believes that.
    - auggierose 5y ago
      Apparently not. I am not against files, actually, I am a big proponent of files. But your statement I quoted is just naive.
      - ghoward 5y ago
        No, I have not shipped any, but I've used plenty, and I hate how such software treats users. Also, I said that it should make it easy, which I understood to mean that there will still be some people for whom it won't help because they simply don't know how or what they did that destroyed their files.