Big list of software that cannot handle spaces or accents in paths
-
@gąska said in Big list of software that cannot handle spaces or accents in paths:
Note that I never said you HAVE to answer that.
@gąska said in Big list of software that cannot handle spaces or accents in paths:
@tsaukpaetra that's not how it works. You made the claim, you support it.
Is this not exactly that?
@gąska said in Big list of software that cannot handle spaces or accents in paths:
I just said I can do zero research and ignore everything you say until you show you're not talking out of your ass.
Why? What could possibly prevent you from googling "can I traverse directories using only identifiers?" or "Can I retrieve current working directory as an identifier?" or "Can I receive files from drag'n'drop as identifiers?" ?
Was my response if "Actually, I think yes. I remember looking into this when researching long file paths. Once you get a handle you can use that to do all sorts of things..." so mind-numbingly radical that it prevented all thought into the matter? I'm thoroughly confused.@gąska said in Big list of software that cannot handle spaces or accents in paths:
"Citation needed" isn't an order; it's an expression of disbelief. A shorter form of "I'll believe it when I see it."
Accepted. However, you immediately derailed the conversation into social expectations with:
@gąska said in Big list of software that cannot handle spaces or accents in paths:
@tsaukpaetra protip: if you don't explicitly state that you don't believe you're correct, people will assume you believe you're correct - and will hold you to the same standards as everyone else who tries to pass their statements as true.
Which in my opinion is bologna. And thence my response:
@tsaukpaetra said in Big list of software that cannot handle spaces or accents in paths:
I think the sky is actually a deep red.
Now, how many people ACTUALLY think I ACTUALLY believe this?
But I'll admit I'm not very good at sarcasm.
By the time you said in Big list of software that cannot handle spaces or accents in paths:
When people start with "I think", it usually means they're pretty damn sure what they say,
I had already clocked out and was in it just for the lolz, because you completely missed my point and didn't appear to want to get it, so I started troll mode. Was I successful? I think so.
@gąska said in Big list of software that cannot handle spaces or accents in paths:
It definitely didn't look like you've had any intention of having serious tech discussion about capabilities of Windows.
No, not after the above.
@gąska said in Big list of software that cannot handle spaces or accents in paths:
BTW - I chose Sydney for a reason.
That's... nice? I don't know very much about culture, so
on me.@gąska said in Big list of software that cannot handle spaces or accents in paths:
You said I'd get better response if I were more polite, and then admitted that no, the responses indeed wouldn't be any better.
No, I admitted I would not have been able to provide sufficient evidence. This is not the same response of stone-walling. For one who claims they know how human communication works., this confuses me.
-
@topspin said in Big list of software that cannot handle spaces or accents in paths:
@gąska said in Big list of software that cannot handle spaces or accents in paths:
@boomzilla the interactive shell is the only program dealing with paths - everything else uses IDs.
lsspits out IDs.grepaccepts IDs.I don't want to read IDs in
lsthough.You won't - the shell will translate them to filenames.
Pipes transfer over IDs.
That doesn't make sense, pipes are a transport mechanism.
And this transport mechanism will transfer IDs. It wouldn't be raw byte stream, though (but it would be possible to make raw byte stream if you need one).
You don't have to worry about quoting and escaping arguments in nested scripts because they're always atomic IDs.
How do things like
for f in *.txt *.log; do ...work? Scripts will have to deal with file names again, anyway. Otherwise I can't write the kind of scripts I write.Is there any reason why
*.txtcan't evaluate to ID instead of path?
-
@gąska said in Big list of software that cannot handle spaces or accents in paths:
Is there any reason why
*.txtcan't evaluate to ID instead of path?It would be a different type of ID, and wouldn't actually be a file ID, really, because you wouldn't necessarily be IDentifying a file at that point.
But, in good faith I have searched MSDN, and the function equivalent that (kinda) does this in Win32 is FindFirstFile, though that of course takes a path-like string and not a file handle.
-
@gąska said in Big list of software that cannot handle spaces or accents in paths:
How do things like
for f in *.txt *.log; do ...work? Scripts will have to deal with file names again, anyway. Otherwise I can't write the kind of scripts I write.Is there any reason why
*.txtcan't evaluate to ID instead of path?You said nested scripts wouldn't deal with file names. That's inside of a script, so I read that as
*.txtshouldn't even be allowed in there. Also, I might want to add further processing to those names in the loop body.
-
@topspin said in Big list of software that cannot handle spaces or accents in paths:
You said nested scripts wouldn't deal with file names. That's inside of a script, so I read that as *.txt shouldn't even be allowed in there.
It's pretty easy to make a class/object that represents either a single file or a set of files. The CLI processor could make IDs that refer to that.
You do program computers, right? Like this "objection" is incredibly easily-solved.
@topspin said in Big list of software that cannot handle spaces or accents in paths:
Also, I might want to add further processing to those names in the loop body.
You can still get the file's name from the ID, naturally. But you shouldn't ever need to.
-
@tsaukpaetra said in Big list of software that cannot handle spaces or accents in paths:
@gąska said in Big list of software that cannot handle spaces or accents in paths:
Note that I never said you HAVE to answer that.
@gąska said in Big list of software that cannot handle spaces or accents in paths:
@tsaukpaetra that's not how it works. You made the claim, you support it.
Is this not exactly that?
I was quoting @Rhywden's own stupid post from yesterday. But jokes aside, there's an implied "or shut up" at the end. I didn't think I need to be explicit about your right not to respond.
@gąska said in Big list of software that cannot handle spaces or accents in paths:
I just said I can do zero research and ignore everything you say until you show you're not talking out of your ass.
Why? What could possibly prevent you from googling "can I traverse directories using only identifiers?" or "Can I retrieve current working directory as an identifier?" or "Can I receive files from drag'n'drop as identifiers?" ?
I could. But the question is, why would I? For all I knew at the moment, it didn't exist. Do you know how hard it is to find something that doesn't exist? Most of the time you won't even find anything that says that the thing you're looking for doesn't exist! The burden of proof was invented to prevent the ridiculous demands to prove a negative.
Was my response if "Actually, I think yes. I remember looking into this when researching long file paths. Once you get a handle you can use that to do all sorts of things..." so mind-numbingly radical that it prevented all thought into the matter? I'm thoroughly confused.
It was a misunderstanding. I thought the discussion is about never ever having to deal with paths in any extent, as this is what the post starting this discussion was about, while you thought - I presume - that the discussion is about there being a way to internally pass files around as handles so you only need to deal with paths at the beginning, to retrieve the handle. When you said "once you get a handle", I thought you mean that the handle is your starting point, while you meant getting the handle from the filename. Then I used one wrong word, you got mad and it went downhill from there.
Note that the first aggressive post ("Search yourself! I'm not your mother. I owe you nothing.") came from you, not me.
@gąska said in Big list of software that cannot handle spaces or accents in paths:
"Citation needed" isn't an order; it's an expression of disbelief. A shorter form of "I'll believe it when I see it."
Accepted. However, you immediately derailed the conversation into social expectations with:
@gąska said in Big list of software that cannot handle spaces or accents in paths:
@tsaukpaetra protip: if you don't explicitly state that you don't believe you're correct, people will assume you believe you're correct - and will hold you to the same standards as everyone else who tries to pass their statements as true.
Which in my opinion is bologna.
It wasn't as much about social expectations as about the meaning of "I think". You acted like it absolved you of having to prove your point.
And thence my response:
@tsaukpaetra said in Big list of software that cannot handle spaces or accents in paths:
I think the sky is actually a deep red.
Now, how many people ACTUALLY think I ACTUALLY believe this?
But I'll admit I'm not very good at sarcasm.
I got the sarcasm. You just forgot that the sky IS sometimes red. Hence my further sarcasm.
By the time you said in Big list of software that cannot handle spaces or accents in paths:
When people start with "I think", it usually means they're pretty damn sure what they say,
I had already clocked out and was in it just for the lolz, because you completely missed my point and didn't appear to want to get it, so I started troll mode. Was I successful? I think so.
You were. But you missed my point at least as much as I missed yours.
@gąska said in Big list of software that cannot handle spaces or accents in paths:
BTW - I chose Sydney for a reason.
That's... nice? I don't know very much about culture, so
on me.It's more about physics, really.
@gąska said in Big list of software that cannot handle spaces or accents in paths:
You said I'd get better response if I were more polite, and then admitted that no, the responses indeed wouldn't be any better.
No, I admitted I would not have been able to provide sufficient evidence. This is not the same response of stone-walling. For one who claims they know how human communication works., this confuses me.
It really depends on what you mean by "better". From purely utilitarian point of view, it doesn't really matter how I learn that there's nothing to learn.
-
@gąska said in Big list of software that cannot handle spaces or accents in paths:
I still don't see how having names is relevant. You could have several IDs refer to the same inode. Also, I've never heard of a legit use case for hard links that wouldn't be better with sift links or regular copies.
With a symlink, the file exists at one location, and the others just point to it. Deleting that file deletes them all. With a hardlink, deleting one file leaves the rest. Hardlinks can also be moved without updating anything; a symlink points at a file path instead of an inode. And lastly symlinks might not always be respected by programs because they're an OS thing instead of a filesystem thing.
-
@pie_flavor said in Big list of software that cannot handle spaces or accents in paths:
And lastly symlinks might not always be respected by programs because they're an OS thing instead of a filesystem thing.
Yeah, got bit by this a few days ago actually. The Perforce client dutifully deleted my soft links in the workspace (that linked to moved-away folders) because they weren't folders. Good times...
-
@gąska said in Big list of software that cannot handle spaces or accents in paths:
Yeah, dot works well enough, why waste precious bytes on dedicated "hidden" attribute?
Windows works fine, by the way.
-
@tsaukpaetra said in Big list of software that cannot handle spaces or accents in paths:
To any that come after the spat above, my pre-emptive response to why I said what I did (besides it being late at night and a bad mood):
I am here on this site under my own desire. I'm not here because it's required or mandated by any outside force.
I post because I want to. My thoughts are usually my own.
You CANNOT demand me to speak about something. And if you do, I'm fully within in rights and abilities to refuse. If you press the issue, I will press back. Attempting to force me to respond will likely cause me to do everything in my power to do the opposite.I would have been glad to look up MSDN for "find file by ID" or similar. It would lead me towards the APIs that take file handles as input, and while they may not do exactly as was described prior, it might have lead to a healthy discussion about it.
However, by coming at me with the ridiculous claim that just because I said something (using "weasel words" notwithstanding) that I'm required, no compulsively obligated to support it, you have effectively removed that desire to reply in good faith, and so you see my response.Hear this: unless you have more reason for me to supply supporting evidence for a statement made in passing than whargarble, I have no requirement to do so, and it is in discretion whether or not to comply.
One does not see a person in the street corner, hear him say something like "man, I don't know what to do, my daughters grades are all Fs and Ds." and then rush over demanding to hear the backstory and proof. This is effectively what happened, and when I said "sod off!" this was the response I was given.
I will not accept that, and cannot be forced to accept that, nor will I back down when someone tells me I "must" do something solely because I wrote something.
this makes no sense I demand evidence
-
@gąska said in Big list of software that cannot handle spaces or accents in paths:
It was a misunderstanding.
@gąska said in Big list of software that cannot handle spaces or accents in paths:
Then I used one wrong word, you got mad and it went downhill from there.
Isn't that how it usually starts though?
-
@pie_flavor said in Big list of software that cannot handle spaces or accents in paths:
this makes no sense I demand evidence
Evidence for what?
-
@tsaukpaetra said in Big list of software that cannot handle spaces or accents in paths:
@pie_flavor said in Big list of software that cannot handle spaces or accents in paths:
this makes no sense I demand evidence
Evidence for what?
-
@topspin said in Big list of software that cannot handle spaces or accents in paths:
@gąska said in Big list of software that cannot handle spaces or accents in paths:
How do things like
for f in *.txt *.log; do ...work? Scripts will have to deal with file names again, anyway. Otherwise I can't write the kind of scripts I write.Is there any reason why
*.txtcan't evaluate to ID instead of path?You said nested scripts wouldn't deal with file names. That's inside of a script, so I read that as
*.txtshouldn't even be allowed in there.It would still pass through interpreter. Though if there was actually a system designed from ground up with lack of paths in mind, free from legacy and from expectations of being similar to other platforms, I doubt there would really be any ".txt" to start with. If anything, it would look more like
for f in `find . -mimetype "text/plain"`;, orfor f in `find . -tag "txt" -or -tag "log"`;.Also, I might want to add further processing to those names in the loop body.
That's what the design is trying to forbid. But hold on for a second - if there are no filenames, why would you want to process filenames?
-
@pie_flavor said in Big list of software that cannot handle spaces or accents in paths:
@gąska said in Big list of software that cannot handle spaces or accents in paths:
I still don't see how having names is relevant. You could have several IDs refer to the same inode. Also, I've never heard of a legit use case for hard links that wouldn't be better with sift links or regular copies.
With a symlink
Who said anything about symlinks? I'm talking about multiple file entries with unique file IDs referring to the same inode.
-
@gąska That's called a hardlink.
-
@pie_flavor my point exactly.
-
@pie_flavor apparently I forgot what I have myself wrote. I thought you're referring to the use case for hard links, not the impossibility of them. I apologize for the confusion.
-
@gąska said in Big list of software that cannot handle spaces or accents in paths:
@pie_flavor my point exactly.
and so I just explained how hardlinks can do things softlinks can't, and you were saying there's no use case for hardlinks instead of softlinks.
-
@pie_flavor said in Big list of software that cannot handle spaces or accents in paths:
@gąska said in Big list of software that cannot handle spaces or accents in paths:
I still don't see how having names is relevant. You could have several IDs refer to the same inode. Also, I've never heard of a legit use case for hard links that wouldn't be better with sift links or regular copies.
With a symlink, the file exists at one location, and the others just point to it. Deleting that file deletes them all. With a hardlink, deleting one file leaves the rest. Hardlinks can also be moved without updating anything; a symlink points at a file path instead of an inode. And lastly symlinks might not always be respected by programs because they're an OS thing instead of a filesystem thing.
OK, but where's the use case?
-
@gąska For when you want to have several large independent identical files that don't use up extra storage. Hardlinks came in great handy when I played Project M, due to needing to maintain several versions of Dolphin with several different save directories and yet needed a big-ass ISO file in all of them.
-
@pie_flavor said in Big list of software that cannot handle spaces or accents in paths:
@gąska For when you want to have several large independent identical files that don't use up extra storage.
Symlinks can do that too. Oh, and copy-on-write. Don't forget copy-on-write!
Hardlinks came in great handy when I played Project M, due to needing to maintain several versions of Dolphin with several different save directories and yet needed a big-ass ISO file in all of them.
And I presume Dolphin crashes on symlinks, and doesn't offer an option to customize save location? Also, out of curiosity - why would you use different emulator versions for the same ROM?
-
@gąska said in Big list of software that cannot handle spaces or accents in paths:
@pie_flavor said in Big list of software that cannot handle spaces or accents in paths:
@gąska For when you want to have several large independent identical files that don't use up extra storage.
Symlinks can do that too. Oh, and copy-on-write. Don't forget copy-on-write!
I said 'independent' and you don't seem to have read it. Independent means they don't depend on each other. A symlink points at an existing file; if the original gets deleted, all get deleted.
Hardlinks came in great handy when I played Project M, due to needing to maintain several versions of Dolphin with several different save directories and yet needed a big-ass ISO file in all of them.
And I presume Dolphin crashes on symlinks, and doesn't offer an option to customize save location? Also, out of curiosity - why would you use different emulator versions for the same ROM?
Netplay compatibility. New versions come with better features, and older versions come with more users. And yes it offers an option to customize save location, but it's better for organization this way.
Fun fact: Minecraft crashes on both symlinks and junctions. Fuck knows how.
-
@pie_flavor said in Big list of software that cannot handle spaces or accents in paths:
@gąska said in Big list of software that cannot handle spaces or accents in paths:
@pie_flavor said in Big list of software that cannot handle spaces or accents in paths:
@gąska For when you want to have several large independent identical files that don't use up extra storage.
Symlinks can do that too. Oh, and copy-on-write. Don't forget copy-on-write!
I said 'independent' and you don't seem to have read it. Independent means they don't depend on each other. A symlink points at an existing file; if the original gets deleted, all get deleted.
Hardlinks came in great handy when I played Project M, due to needing to maintain several versions of Dolphin with several different save directories and yet needed a big-ass ISO file in all of them.
And I presume Dolphin crashes on symlinks, and doesn't offer an option to customize save location? Also, out of curiosity - why would you use different emulator versions for the same ROM?
Netplay compatibility. New versions come with better features, and older versions come with more users. And yes it offers an option to customize save location, but it's better for organization this way.
Fun fact: Minecraft crashes on both symlinks and junctions. Fuck knows how.Do Win32/Win64 JVMs handle those kinds of things?
-
@mikehurley It should. But knowing Java...
-
@pie_flavor said in Big list of software that cannot handle spaces or accents in paths:
@gąska said in Big list of software that cannot handle spaces or accents in paths:
@pie_flavor said in Big list of software that cannot handle spaces or accents in paths:
@gąska For when you want to have several large independent identical files that don't use up extra storage.
Symlinks can do that too. Oh, and copy-on-write. Don't forget copy-on-write!
I said 'independent' and you don't seem to have read it. Independent means they don't depend on each other. A symlink points at an existing file; if the original gets deleted, all get deleted.
This is easily solvable by having main folder with actual file and per-version folder with symlinks. It's not the same, but it serves the same purpose. As an added bonus, to free up space, you only have to delete it once - and if you want it back later, you don't have to recreate all the links. As we say here in Poland - something for something.
Hardlinks came in great handy when I played Project M, due to needing to maintain several versions of Dolphin with several different save directories and yet needed a big-ass ISO file in all of them.
And I presume Dolphin crashes on symlinks, and doesn't offer an option to customize save location? Also, out of curiosity - why would you use different emulator versions for the same ROM?
Netplay compatibility. New versions come with better features, and older versions come with more users.
Fair enough.
And yes it offers an option to customize save location, but it's better for organization this way.
Don't get me wrong, but it really sounds like a Vim user saying doing everything through multilevel shortcuts is more efficient than GUI. I think the only reason you think it's better is because you're used to it.
Fun fact: Minecraft crashes on both symlinks and junctions. Fuck knows how.
-
@pie_flavor said in Big list of software that cannot handle spaces or accents in paths:
Fun fact: Minecraft crashes on both symlinks and junctions. Fuck knows how.
It didn't used to. When I played years ago I had a symlink pointing to a dropbox folder for my Minecraft saves and it worked just fine.
-
@blakeyrat I guess I just don't see the (non-)problem this is supposed to solve. Sure, the original complaint that non-printable characters in names is way stupid I agree with (and the thread topic's encoding problems too), but not using file names in general doesn't entice me.
-
@topspin I don't think anybody in this thread said "don't use file names". Not sure where this is coming from.
-
@blakeyrat Not using names to identify files.
-
@topspin Humans use names to identify files (along with other meta-data.)
Computer programs never do.
That's the idea.
-
@blakeyrat Yeah, I don't see what this is solving.
-
@topspin said in Big list of software that cannot handle spaces or accents in paths:
@blakeyrat I guess I just don't see the (non-)problem this is supposed to solve. Sure, the original complaint that non-printable characters in names is way stupid I agree with (and the thread topic's encoding problems too), but not using file names in general doesn't entice me.
Have you never had problems with spaces in names? Have you never had problems with escaping or unescaping not working correctly? Have you never seen a bug in parent-directory-extraction-from-path function? Have you never had problems with programs using the wrong base directory for relative paths?
Wouldn't you want to get rid of 90% of regexes in existence?
-
@gąska Just feel that it's 1) just shifting the problems around into yet another layer and 2) introduce other problems related to "you have what you think is an ID (file name) and an
mysql_real_idactual ID".
-
@topspin said in Big list of software that cannot handle spaces or accents in paths:
@gąska Just feel that it's 1) just shifting the problems around into yet another layer
It is. And by doing so, we've created a situation where there's only a couple of places in the entire operating system that actually has to deal with filenames in non-trivial way (ie. anything more than just read and display them on screen) - so there's only so many places you have to check if they handle it correctly. You can't get it wrong if you're not doing it in the first place.
and 2) introduce other problems related to "you have what you think is an ID (file name) and an
mysql_real_idactual ID".Except it doesn't. Save for reinterpret casts and serialization bugs, there's no way a valid ID stops being a valid ID or starts referring to something else than it was originally - because you're never transforming them in any way. You don't have to split IDs, escape IDs, unquote IDs - and, again, you can't get it wrong if you're not doing it.
-
@gąska said in Big list of software that cannot handle spaces or accents in paths:
Sure, if you didn't use the inode itself but kept another ID referring to the inode that was stored on disk separate from both inodes and directories, that would work. It would fail with any file system that didn't explicitly support it though, which is basically everybody else's.
Filename is literally another ID referring to the inode. Every filesystem in existence already supports that.
Of course, but what you asked for is yet another ID that's neither inode nor filename.
If I got that right, you liked MacOS' idea that an application opens a file by ID and then keeps only that ID around so when it saves that file back to disk, it would write to the same file even if it has meanwhile been moved or renamed.
Imagine someone deletes the file while I'm working on it, or someone privileged comes along and moves the file somewhere that I'm not permitted to enter. What should happen?Have Unix permissions evolved beyond rwxr-xr-x? If so, TIL.
Well, the second rwx is for a specific group. That the owner doesn't strictly have to be a member of, although only root can give files to such groups. And yes, POSIX.1e ACLs have been supported for about 15 years, too.
Huh. TIL. But it kinda misses my point - I meant that you cannot have more than one group for a given file that have permissions other than the default permissions that everyone has.
That's right, without ACLs you have exactly one group for any file. But Unix has supported ACLs since way before NT, and Linux since the early noughties, so they're there if you feel like using them. I never have since university where we had some complicated workgroup setups that seemed to be there mostly because to show off IRIX, "because we can".
The sticky bit predates Linux by over half a decade BTW.
s/Linux/Unix/. Happy now?(y)
@gąska said in Big list of software that cannot handle spaces or accents in paths:
@boomzilla the interactive shell is the only program dealing with paths - everything else uses IDs.
lsspits out IDs.grepaccepts IDs. Pipes transfer over IDs. You don't have to worry about quoting and escaping arguments in nested scripts because they're always atomic IDs.If that's your worry, that's far easier to fix without jumping through ridiculous hoops that nobody has used since the 90s fr good reason.
@gąska said in Big list of software that cannot handle spaces or accents in paths:
I remember removing my own write and delete permissions from a specific file in browser AppData folder to prevent them from messing up my settings. The problem is that the entire rest of the folder needs full permissions for the browser to work correctly.
As a bandaid like that,
chattr +i file ...has you covered.@blakeyrat said in Big list of software that cannot handle spaces or accents in paths:
You know it might just be possible that BOTH Linux AND Windows suck? And that by saying "Linux sucks" I'm not also saying "and BTW Windows is really good". Did you stop to think of that?
When you're saying
The problem isn't that POSIX/Linux is a different design, the problem is that it's a bad design that makes it virtually impossible to write 100% correct code.
That pretty much implies there existed a better design. I can only guess at which one you could have meant from your previous wordings such as "you put a shitty broken Linux disk into a Windows machine". I'm sorry if I assumed your default OS_RELIGION_ID there, but it just has to be a guess if your posting spec doesn't include it.
-
@laoc said in Big list of software that cannot handle spaces or accents in paths:
That pretty much implies there existed a better design.
It does, yes.
Does it imply that Windows is that better design? No, no it does not. That information comes only from your own head, not anything I typed.
I'm sorry that your retarded moron-brain is incapable of reading the words I put on the screen without also inserting tons of imaginary words I did not put on the screen, but that is your problem, not mine.
-
@laoc said in Big list of software that cannot handle spaces or accents in paths:
@gąska said in Big list of software that cannot handle spaces or accents in paths:
Sure, if you didn't use the inode itself but kept another ID referring to the inode that was stored on disk separate from both inodes and directories, that would work. It would fail with any file system that didn't explicitly support it though, which is basically everybody else's.
Filename is literally another ID referring to the inode. Every filesystem in existence already supports that.
Of course, but what you asked for is yet another ID that's neither inode nor filename.
Yes, except filename would stop being identifying feature. Which would leave you with only two IDs to deal with - file ID and inode.
If I got that right, you liked MacOS' idea that an application opens a file by ID and then keeps only that ID around so when it saves that file back to disk, it would write to the same file even if it has meanwhile been moved or renamed.
No, I liked the MacOS's idea that an application open files by ID so it never has to do string manipulation on paths. Moving etc. is another discussion that I don't have a side in (though the problem you talk about can be avoided with RW locks).
Have Unix permissions evolved beyond rwxr-xr-x? If so, TIL.
Well, the second rwx is for a specific group. That the owner doesn't strictly have to be a member of, although only root can give files to such groups. And yes, POSIX.1e ACLs have been supported for about 15 years, too.
Huh. TIL. But it kinda misses my point - I meant that you cannot have more than one group for a given file that have permissions other than the default permissions that everyone has.
That's right, without ACLs you have exactly one group for any file. But Unix has supported ACLs since way before NT, and Linux since the early noughties, so they're there if you feel like using them. I never have since university where we had some complicated workgroup setups that seemed to be there mostly because to show off IRIX, "because we can".
Oh, so you can have more than one group that's treated specially? Do they share permission or can you specify it per group? Can you have 0 groups?
@gąska said in Big list of software that cannot handle spaces or accents in paths:
@boomzilla the interactive shell is the only program dealing with paths - everything else uses IDs.
lsspits out IDs.grepaccepts IDs. Pipes transfer over IDs. You don't have to worry about quoting and escaping arguments in nested scripts because they're always atomic IDs.If that's your worry, that's far easier to fix without jumping through ridiculous hoops that nobody has used since the 90s fr good reason.
If I didn't trip on it over and over and over again in programs I cannot modify, there wouldn't be a problem. But even in 2018 I need several tries before I get escaping right for a given script - with every mistake carrying some risk of irrecoverably losing data in random files.
@gąska said in Big list of software that cannot handle spaces or accents in paths:
I remember removing my own write and delete permissions from a specific file in browser AppData folder to prevent them from messing up my settings. The problem is that the entire rest of the folder needs full permissions for the browser to work correctly.
As a bandaid like that,
chattr +i file ...has you covered.But I'm still the owner then, and programs run as me still can delete it.
@blakeyrat said in Big list of software that cannot handle spaces or accents in paths:
You know it might just be possible that BOTH Linux AND Windows suck? And that by saying "Linux sucks" I'm not also saying "and BTW Windows is really good". Did you stop to think of that?
When you're saying
The problem isn't that POSIX/Linux is a different design, the problem is that it's a bad design that makes it virtually impossible to write 100% correct code.
That pretty much implies there existed a better design. I can only guess at which one you could have meant from your previous wordings such as "you put a shitty broken Linux disk into a Windows machine". I'm sorry if I assumed your default OS_RELIGION_ID there, but it just has to be a guess if your posting spec doesn't include it.
Have you considered the possibility that this better design hasn't been implemented anywhere? And not because it isn't better. There are many reasons why better designs aren't implemented by anyone. Look at gamepads - all of them have just 10 buttons even though there's room for more, and many games would use more buttons (they have multiple actions bound to one button - usually jump/sprint, jump/action, attack/action).
-
@blakeyrat said in Big list of software that cannot handle spaces or accents in paths:
@laoc said in Big list of software that cannot handle spaces or accents in paths:
That pretty much implies there existed a better design.
It does, yes.
Does it imply that Windows is that better design? No, no it does not. That information comes only from your own head, not anything I typed.
Seems I have to repeat it.
I can only guess at which one you could have meant from your previous wordings such as "you put a shitty broken Linux disk into a Windows machine". I'm sorry if I assumed your default OS_RELIGION_ID there, but it just has to be a guess if your posting spec doesn't include it.your retarded moron-brain
Love you too
-
@blakeyrat said in Big list of software that cannot handle spaces or accents in paths:
Humans use names to identify files (along with other meta-data.)
Computer programs never do.Except that computer programs have to interact with people, so yes, computer programs actually do need to use names to identify things. And computers are actually pretty good at handling names too.
-
@laoc said in Big list of software that cannot handle spaces or accents in paths:
@blakeyrat said in Big list of software that cannot handle spaces or accents in paths:
@laoc said in Big list of software that cannot handle spaces or accents in paths:
That pretty much implies there existed a better design.
It does, yes.
Does it imply that Windows is that better design? No, no it does not. That information comes only from your own head, not anything I typed.
Seems I have to repeat it.
I can only guess at which one you could have meant from your previous wordings such as "you put a shitty broken Linux disk into a Windows machine". I'm sorry if I assumed your default OS_RELIGION_ID there, but it just has to be a guess if your posting spec doesn't include it.YMBNH. Everyone knows his beloved OS is Mac Classic.
-
@dkf said in Big list of software that cannot handle spaces or accents in paths:
@blakeyrat said in Big list of software that cannot handle spaces or accents in paths:
Humans use names to identify files (along with other meta-data.)
Computer programs never do.Except that computer programs have to interact with people, so yes, computer programs actually do need to use names to identify things.
So when they have to interact with people, they would use filenames there. But guess what - it turns out there isn't that much code that interacts with people after all! Only the UI has to deal with displaying names, and most code in existence is non-UI. Even in GUI apps. And parsing paths to files also has to happen only in UI, and only in one specific kind of UI - interactive shell, and only on input.
And computers are actually pretty good at handling names too.
ThIs entire thread is about computers NOT handling names correctly. Just read the title.
-
@gąska said in Big list of software that cannot handle spaces or accents in paths:
it turns out there isn't that much code that interacts with people after all
Then stop bitching about it to us obvious luddites here, and go off and build your techno-nirvana. Prove yourself by doing it.
-
@gąska said in Big list of software that cannot handle spaces or accents in paths:
Filename is literally another ID referring to the inode. Every filesystem in existence already supports that.
Of course, but what you asked for is yet another ID that's neither inode nor filename.
Yes, except filename would stop being identifying feature. Which would leave you with only two IDs to deal with - file ID and inode.
So you want to store the ID in the same structures that file systems commonly use for the name (that which every file system in existence already supports) … and then add names where?
Not that this changed anything; for a name-to-ID-and-back translation to work you still need a bijective mapping between the two.If I got that right, you liked MacOS' idea that an application opens a file by ID and then keeps only that ID around so when it saves that file back to disk, it would write to the same file even if it has meanwhile been moved or renamed.
No, I liked the MacOS's idea
If you want to pick spelling nits, do it properly. "MacOS" is a proper name.
that an application open files by ID so it never has to do string manipulation on paths. Moving etc. is another discussion that I don't have a side in (though the problem you talk about can be avoided with RW locks).
So you'd forbid doing the exact thing people found cool about the feature in the 90s to hack around the problems you'd get from implementing the feature in a modern environment.
That's right, without ACLs you have exactly one group for any file. But Unix has supported ACLs since way before NT, and Linux since the early noughties, so they're there if you feel like using them. I never have since university where we had some complicated workgroup setups that seemed to be there mostly because to show off IRIX, "because we can".
Oh, so you can have more than one group that's treated specially?
Yes.
Do they share permission or can you specify it per group?
Per group. Or user.
Can you have 0 groups?
No, there is always at least one group. It can have zero permissions of course.
If that's your worry, that's far easier to fix without jumping through ridiculous hoops that nobody has used since the 90s fr good reason.
If I didn't trip on it over and over and over again in programs I cannot modify, there wouldn't be a problem. But even in 2018 I need several tries before I get escaping right for a given script - with every mistake carrying some risk of irrecoverably losing data in random files.
@blakeyrat linked an article recently that proposes much simpler and less hacky fixes.
As a bandaid like that,
chattr +i file ...has you covered.But I'm still the owner then, and programs run as me still can delete it.
No.
Have you considered the possibility that this better design hasn't been implemented anywhere? And not because it isn't better. There are many reasons why better designs aren't implemented by anyone. Look at gamepads - all of them have just 10 buttons even though there's room for more, and many games would use more buttons (they have multiple actions bound to one button - usually jump/sprint, jump/action, attack/action).
Gamepads?! I don't really have a clue about gamepads as I haven't used one in ages but the way I see it people use them because they want to keep one hand one some kind of joystick-or-equivalent and the other on a bunch of action buttons that don't require a touch typing course for every new game you play. The gamepad for people who need a huge number of buttons that they can intuitively use is called a keyboard.
Maybe that better design you're missing hasn't been implemented because most people see it as a worse design. Which would fit that file system idea quite well.Edit: fix typo
-
@dkf I knew it. I fucking knew it you would misunderstand that part.
Take a random WPF project. How many lines of code are in .cs files? How many lines are in .xaml and .xaml.cs files? Most code isn't UI even though it gets called by UI.
If I had time and money, you can be damn sure I would start an OS project (or virtual env project that would have all that but be backed by existing OS) where paths (NOT names - just paths) would be made as hard to work it, while making files IDs so easy to use and just as powerful that all software would default to using IDs and not paths, eliminating whole classes of bugs. But I have neither, and won't have them in foreseeable future. If you want to fund me - go ahead, I'll gladly accept donations. Just don't expect me to do anything before the funding hits $300k.
-
@gąska said in Big list of software that cannot handle spaces or accents in paths:
Look at gamepads - all of them have just 10 buttons even though there's room for more, and many games would use more buttons (they have multiple actions bound to one button - usually jump/sprint, jump/action, attack/action).
Microsoft screwed everyone there with XInput; 10 buttons is all you can have. Consoles have forever only supported specific input types, but XInput brought those limitations to Windows.
-
@gąska said in Big list of software that cannot handle spaces or accents in paths:
If you want to fund me - go ahead, I'll gladly accept donations. Just don't expect me to do anything before the funding hits $300k.
The "Dumb things being crowdfunded" thread is
-
@gąska said in Big list of software that cannot handle spaces or accents in paths:
Take a random WPF project.
I don't have any at all. Indeed, my current projects are both entirely using other tech stacks and, for good internal reasons, virtually all of them have no GUI code either. (Their “user interface” is in the form of commands within a scripting language; for what I'm doing that makes much more sense.)
But that nitpick aside, there are a substantial number of complications for you to think about as part of your cunning plan. First of them is that files (which are in general bags of bytes, but which might be programs or serialisations of objects or any number of other mostly-fixed things) have quite a need to refer to other files. That means that you're going to need to embed these IDs and that means that you need your system to handle all that side of stuff. You'll also need ways to group files together because they are related in some way (as opposed to just using the filename with a different extension), which means that you'll need some sort of generalised relational graph system. There are probably other tricky bits too, but this is a rabbit hole I've never jumped down.
These ideas have been around for quite a while and there are various attempts out there at doing them, but making them work well is quite challenging! Probably harder than that. The biggest problem you have is that a vast preponderance of existing technology simply doesn't work that way. A related problem is that the implementations that have been have also been catastrophically nasty and slow to use: I know a little bit about the generalised relational graph stuff; it's what lead to RDF and the implementations of it are well known to be slow dogs due to the underlying models being overwhelmingly fond of doing database queries with vast numbers of self-joins. At the same time, RDF tends to be nearly completely undiscoverable because the relations are so unconstrained. Horrible. Optimising those things usually consists of throwing away the genericity and using a normal SQL database as those work very well indeed.
I am, of course, not giving you any money. I think what you're contemplating trying to do is a Bad Idea for reasons that you're ignoring. I don't give money to things that I think are bad ideas.
-
@parody said in Big list of software that cannot handle spaces or accents in paths:
@gąska said in Big list of software that cannot handle spaces or accents in paths:
Look at gamepads - all of them have just 10 buttons even though there's room for more, and many games would use more buttons (they have multiple actions bound to one button - usually jump/sprint, jump/action, attack/action).
Microsoft screwed everyone there with XInput; 10 buttons is all you can have. Consoles have forever only supported specific input types, but XInput brought those limitations to Windows.
What about DirectInput?
-
@laoc said in Big list of software that cannot handle spaces or accents in paths:
@gąska said in Big list of software that cannot handle spaces or accents in paths:
Filename is literally another ID referring to the inode. Every filesystem in existence already supports that.
Of course, but what you asked for is yet another ID that's neither inode nor filename.
Yes, except filename would stop being identifying feature. Which would leave you with only two IDs to deal with - file ID and inode.
So you want to store the ID in the same structures that file systems commonly use for the name (that which every file system in existence already supports) … and then add names where?
Metadata, of course. Windows and MacOS already
Not that this changed anything; for a name-to-ID-and-back translation to work you still need a bijective mapping between the two.
If I got that right, you liked MacOS' idea that an application opens a file by ID and then keeps only that ID around so when it saves that file back to disk, it would write to the same file even if it has meanwhile been moved or renamed.
No, I liked the MacOS's idea
If you want to pick spelling nits, do it properly. "MacOS" is a proper name.
According to your link, I was right.
that an application open files by ID so it never has to do string manipulation on paths. Moving etc. is another discussion that I don't have a side in (though the problem you talk about can be avoided with RW locks).
So you'd forbid doing the exact thing people found cool about the feature in the 90s to hack around the problems you'd get from implementing the feature in a modern environment.
For the last time: I DON'T SUPPORT BEING ABLE TO RENAME A FILE IN USE. NEITHER AM I AGAINST IT. STOP PESTERING ME ABOUT THINGS I HAVE NO OPINION ON.
Although the RWLock could be made on parent directory only, allowing the name itself to change. And it doesn't necessarily have to be full lock - it would be enough to check if all file openers have the same permissions in target destination as the ones they opened the file with.
That's right, without ACLs you have exactly one group for any file. But Unix has supported ACLs since way before NT, and Linux since the early noughties, so they're there if you feel like using them. I never have since university where we had some complicated workgroup setups that seemed to be there mostly because to show off IRIX, "because we can".
Oh, so you can have more than one group that's treated specially?
Yes.
Do they share permission or can you specify it per group?
Per group. Or user.
Good to know. I wish more Linux gurus knew about this feature - it doesn't seem to be common knowledge.
If that's your worry, that's far easier to fix without jumping through ridiculous hoops that nobody has used since the 90s fr good reason.
If I didn't trip on it over and over and over again in programs I cannot modify, there wouldn't be a problem. But even in 2018 I need several tries before I get escaping right for a given script - with every mistake carrying some risk of irrecoverably losing data in random files.
@blakeyrat linked an article recently that proposes much simpler and less hacky fixes.
How many pages ago was it? I must have missed it. Also, I don't see anything "hacky" about having a nice, strongly-typed, system-wide API for every operation you might ever need.
As a bandaid like that,
chattr +i file ...has you covered.But I'm still the owner then, and programs run as me still can delete it.
No.
So, sticky bit disallows owner from deleting it too? That's not what I was told earlier in the topic. Also, how well supported is it in practice? I'm asking because for example, running script via
bash scriptignores executable permission - and many people execute scripts that way rather than by./script. If sticky bit wasn't always enforced, it wouldn't be very useful (not totally useless, but not that useful either).Have you considered the possibility that this better design hasn't been implemented anywhere? And not because it isn't better. There are many reasons why better designs aren't implemented by anyone. Look at gamepads - all of them have just 10 buttons even though there's room for more, and many games would use more buttons (they have multiple actions bound to one button - usually jump/sprint, jump/action, attack/action).
Gamepads?! I don't really have a clue about gamepads
Okay, forget it. I'll let you know if I come up with an example you can relate to more.
Maybe that better design you're missing hasn't been implemented because most people see it as a worse design.
Or maybe because there wasn't enough incentive to try anything else. Look at C++ - the 2011 version was objectively better in every way from 2003 version with no downsides, yet it took years for most companies to make the switch (many still haven't done it, though thankfully it's a dying species).
The point is, no one using something isn't proof that something is bad.
