So I decided to try to update part of my toolchain...

Applied Mediocrity

@Gąska said in So I decided to try to update part of my toolchain...:

Which problem are you talking about now? Are we still talking about OS design or are we now full psychology?

Yes. There's very little use in solving a technical problem and patting ourselves on the backs for a job well done when people keep misusing it (as they are usually wont to do, for the sake of convenience and other, less valid reasons).

I don't see where you're going with it. Scripting is essentially program with larger permissions launching programs with smaller permissions, and the "larger" program temporarily expanding permissions of programs it launches. What's the problem here?

The blanket permissions are the problem. Can one guarantee that the program will not misuse the permission for convoluted, but perhaps technically valid purposes?

And now I'm completely lost. How "what" can ever be a problem?

I believe I stated it in a form of a question, and honestly so, if it needs to be stressed here.

That said, I cannot imagine how it can ever not be a problem. I don't really trust any program to behave rationally, ever. And many don't. Unfortunately, in practice certain concessions are necessary.

Consider, for instance, a program that collects telemetry data. It's been given a blanket permission to write files to certain user directory, because it's also an editor of certain file types. And so it does. It would rather hide the files away in some obscure Temp/AppData/ProgramData/whatever, but if it's not allowed, it will happily write where it can.

And how is "where" a non-issue?

I didn't intend to say that it is a non-issue, rather that it's not the only issue and perhaps not even the most important one.

HardwareGeek

@izzion said in So I decided to try to update part of my toolchain...:

Dude, man, censor that cuss word! It's way too vile to be posted to a publicly accessible portion of the forum!

Some people even post "B*****m" without censoring it!

Gąska

@Applied-Mediocrity said in So I decided to try to update part of my toolchain...:

@Gąska said in So I decided to try to update part of my toolchain...:

Which problem are you talking about now? Are we still talking about OS design or are we now full psychology?

Yes. There's very little use in solving a technical problem and patting ourselves on the backs for a job well done when people keep misusing it (as they are usually wont to do, for the sake of convenience and other, less valid reasons).

I disagree. There are different kind of users, each with different needs. There's a large number of computer users - not majority by any means, but still a sizable group - who understand security enough to not mindlessly click "yes" on every dialog that appears. Solving a problem that would greatly help this group, with minimal impact on the other group, is absolutely worth it. And smartphone permission system does exactly that.

I'm not talking about spherical computers in vacuum. I'm talking about solving real problems of real people - not all the problems and not all the people, but still.

I don't see where you're going with it. Scripting is essentially program with larger permissions launching programs with smaller permissions, and the "larger" program temporarily expanding permissions of programs it launches. What's the problem here?

The blanket permissions are the problem.

There are many ways to make permissions granular without crippling usability.

Can one guarantee that the program will not misuse the permission for convoluted, but perhaps technically valid purposes?

Can one guarantee that the program will not contain an easily exploitable bug allowing remote code execution and privilege escalation? You're asking for too much.

And now I'm completely lost. How "what" can ever be a problem?

I believe I stated it in a form of a question, and honestly so, if it needs to be stressed here.

I'm still unclear on what "what" you were referring to. All I'm seeing is "who" (stupid users) and "why" ().

That said, I cannot imagine how it can ever not be a problem. I don't really trust any program to behave rationally, ever. And many don't. Unfortunately, in practice certain concessions are necessary.

Exactly. Completely isolating all programs is both impossible and infeasible - however, mostly isolating most programs is still a huge win, and entirely practical.

Consider, for instance, a program that collects telemetry data. It's been given a blanket permission to write files to certain user directory, because it's also an editor of certain file types.

That's already too much permissions. A file editor should only have permission to access files it was launched with, and to open save dialog. No direct access to arbitrary files.

It would rather hide the files away in some obscure Temp/AppData/ProgramData/whatever, but if it's not allowed

And this is too low permissions. Every program must at the very least have access to an isolated scratchpad space (Temp, but secure) and to an isolated persistent storage (AppData, but secure). These are basic capabilities that almost no program can function without, and there's zero security cost to providing them (exploiting vulnerabilites to break out of sandbox notwithstanding). Coincidentally, that's exactly like UWP works. The only problem might be storage size, but that can be taken care of too, and it's not like we particularly care about it right now either.

Groaner

@Gąska said in So I decided to try to update part of my toolchain...:

@Groaner said in So I decided to try to update part of my toolchain...:

@M_Adams said in So I decided to try to update part of my toolchain...:

Well at least they’ll sort in the proper order.

Until November 20, 2286 at 17:46:40+00:00.

Not on Windows. Windows is smart enough to sort numbers as a whole, not digit by digit.

Wouldn't that break assumptions with respect to ASCIIbetical sorting, or was breaking such sorting a conscious decision?

Now that you mention it, I remember an Old New Thing post about sniffing date formats and it had a section on Unix timestamps. Thing is, I'm not sure any such assumptions would hold beyond January 19, 2038.

Gąska

@Groaner said in So I decided to try to update part of my toolchain...:

@Gąska said in So I decided to try to update part of my toolchain...:

@Groaner said in So I decided to try to update part of my toolchain...:

@M_Adams said in So I decided to try to update part of my toolchain...:

Well at least they’ll sort in the proper order.

Until November 20, 2286 at 17:46:40+00:00.

Not on Windows. Windows is smart enough to sort numbers as a whole, not digit by digit.

Wouldn't that break assumptions with respect to ASCIIbetical sorting, or was breaking such sorting a conscious decision?

The latter. Who cares about ASCIIbetical sorting?

Parody

@boomzilla said in So I decided to try to update part of my toolchain...:

Ugh. I hate that our blakeyrants are stuck in the 2000s. IT'S 2019 PEOPLE!

Between recreating the Classic MacOS file handling setup and sudo it's been a pretty big time warp.

Groaner

@boomzilla said in So I decided to try to update part of my toolchain...:

Ugh. I hate that our blakeyrants are stuck in the 2000s. IT'S 2019 PEOPLE!

Your logical fallacy is: Argumentum ad Currentyearum

Groaner

~~95%~~85% DONE!

Getting the project compiling and running was only the first step. Next came dealing with runtime errors. Many of them centered on new Ogre being strict about case-sensitivity and the like, which shouldn't be surprising by this point.

The most exciting errors were in plugins that inherited from an object with an mName and then added an mName of their own. Without checking the standard, I have a hunch that this sort of shadow/overriding behavior would be something that would have changed with C++11. Also, what's the deal with the Hungarian prefix m? Didn't that antipattern die out a good decade and a half ago? I can tell if a variable is a member or not by mousing over it and looking at what Intellisense tells me.

It also took me a little while to chase down a vector iterator not incrementable exception in a cleanup method as the delete loop kept failing to delete an object named "OgreOggListener" when it was supposed to be looking for an object named "OgreOggSoundListener", and then incrementing the iterator as hasMoreElements() kept returning true. I make the names match in the offending plugin and the problem disappears!

Now that it seems most of the showstopper bugs have been addressed, I'm working on getting the Release build ready (for which the vast majority of work has been done already, just need to use different DLLs) and a RelWithDebInfo build because getting 3 FPS when you just want to step into the code and inspect variables is annoying.

Ogitor's still sitting on 1.9, and I could port that over at some point, but I'm happy enough to have my actual project and its stack on VS 2017 and 1.11.

Carnage

@Groaner said in So I decided to try to update part of my toolchain...:

Also, what's the deal with the Hungarian prefix m? Didn't that antipattern die out a good decade and a half ago? I can tell if a variable is a member or not by mousing over it and looking at what Intellisense tells me.

I have vague memories of having configured Emacs to color variables by scope as well, way back in $LONG_AGO so I never really got the hungry notation, nor liked it. Cancerous warts all over shortened variable names.

Groaner

@Carnage said in So I decided to try to update part of my toolchain...:

@Groaner said in So I decided to try to update part of my toolchain...:

Also, what's the deal with the Hungarian prefix m? Didn't that antipattern die out a good decade and a half ago? I can tell if a variable is a member or not by mousing over it and looking at what Intellisense tells me.

I have vague memories of having configured Emacs to color variables by scope as well, way back in $LONG_AGO so I never really got the hungry notation, nor liked it. Cancerous warts all over shortened variable names.

Even Joel's defense of its almost-virtues falls flat. If you're afraid of assigning relative coordinates to pixel dimensions, the solution is to make a RelativeCoordinate class and PixelCoordinate class and have operations between the two that handle the distinction, or naming variables like window_relative_position or width_in_pixels. Anything but rlWindPos or pxWidth. I guess there were limits on variable name lengths in the mid 1980's, though?

HardwareGeek

@Groaner said in So I decided to try to update part of my toolchain...:

I guess there were limits on variable name lengths in the mid 1980's, though?

In C, there has never been a maximum identifier length. However, there was a maximum length that was guaranteed to be significant. The compiler free to ignore the rest of the name.

int abcdefghij; 
int abcdefghyz;

might result in a duplicate declaration error in pre-ANSI C, because the compiler might only consider the first 8 characters in the name (increased to 31 in C89, later increased to 63).

Even worse, external identifiers — those used by the linker — were limited to 6 characters, case-insensitive. Again, you could use longer names, but the first 6 characters had to be unique; window_relative_position and window_absolute_position were liable to be considered the same variable, window. This limitation has been raised to the first 31 characters in the current standard.

Tsaukpaetra

@Gąska said in So I decided to try to update part of my toolchain...:

you wouldn't believe how people here reacted the last time I proposed UID-only filesystem

Something tells me that's an extremely small slice of the picture...

pie_flavor

@acrow said in So I decided to try to update part of my toolchain...:

And I don't doubt for a second that, should we move to UUID filesystems, any "creator" or "owned by program" field will read "<insert owner here>" on at least half of all software.

How's that? Standardized package system, program name is not optional. Easy.

P.S. I've read enough articles about UWP failing to install an app, nevermind un-installing them, that I think you really should not use it as an example.

You say that like I don't know. UWP right now on my computer refuses to launch any app that contains an exe file. The point is the underlying concepts.

pie_flavor

@boomzilla said in So I decided to try to update part of my toolchain...:

@pie_flavor said in So I decided to try to update part of my toolchain...:

Also, apps needing to have uninstallers instead of using system-provided methods is TRWTF - no such thing is required in the UWP system.

I've been told this is all about anti-trust.

Standardized package system != standard repository location, and standard repository location != locked down to only that location (looking at you, Apple).

pie_flavor

@dcon said in So I decided to try to update part of my toolchain...:

@pie_flavor said in So I decided to try to update part of my toolchain...:

no such thing is required in the UWP system

Last I knew, the UWP system can't do services or drivers or COM. All of those require a lot more installation handholding than just dropping files into a file system. (Tho you can get away with registry-free COM in some situations)

That's its own fault for not making a way to do services and drivers and COM. It's a limitation of the implementation, not of the concept.

pie_flavor

@dkf said in So I decided to try to update part of my toolchain...:

OTOH, merely having the creator of a file go away shouldn't delete the files created by that program. Deleting a user's pictures just because they deleted the photo editor they were using at one point is a bad plan!

And so you'd also set a type field, to mark it as a document, program file, user configuration file, program configuration file, etc.

Tsaukpaetra

@pie_flavor said in So I decided to try to update part of my toolchain...:

Boom, you know which files were left behind.

> uninstalls photo editor program
> operating system "cleans up"
> all photos gone.
> world is better place.

Edit: dammit. @dkf knew my mind!

dkf

@HardwareGeek said in So I decided to try to update part of my toolchain...:

However, there was a maximum length that was guaranteed to be significant.

Wouldn't that be a minimum length? After all, compilers and other related tools are free to consider more characters than the standard requires.

dkf

@pie_flavor said in So I decided to try to update part of my toolchain...:

@dkf said in So I decided to try to update part of my toolchain...:

OTOH, merely having the creator of a file go away shouldn't delete the files created by that program. Deleting a user's pictures just because they deleted the photo editor they were using at one point is a bad plan!

And so you'd also set a type field, to mark it as a document, program file, user configuration file, program configuration file, etc.

Yep. It's reinventing the Mac classic way of doing things.

acrow

@pie_flavor said in So I decided to try to update part of my toolchain...:

@dcon said in So I decided to try to update part of my toolchain...:

@pie_flavor said in So I decided to try to update part of my toolchain...:

no such thing is required in the UWP system

Last I knew, the UWP system can't do services or drivers or COM. All of those require a lot more installation handholding than just dropping files into a file system. (Tho you can get away with registry-free COM in some situations)

That's its own fault for not making a way to do services and drivers and COM. It's a limitation of the implementation, not of the concept.

True. But it also points out the reason why the concept can never be dominant in non-consumer applications; it prevents new concepts and technologies by default.

acrow

@pie_flavor said in So I decided to try to update part of my toolchain...:

@dkf said in So I decided to try to update part of my toolchain...:

OTOH, merely having the creator of a file go away shouldn't delete the files created by that program. Deleting a user's pictures just because they deleted the photo editor they were using at one point is a bad plan!

And so you'd also set a type field, to mark it as a document, program file, user configuration file, program configuration file, etc.

Why stop there? We could collect all the configurations into a single place. That way, we can make sure that they're never accidentally altered, deleted or corrupted. Let's call it... uhh... a Registry!

Gąska

@acrow it would be awesome for each program to get its own isolated registry hive.

ixvedeusi

@dcon said in So I decided to try to update part of my toolchain...:

My point is that when you start asking users for permission, you piss them off. That's my point about UAC - when it first came out, many just disabled it.

The main problem with UAC (and sudo) is that there's only two modes "don't let this program do anything at all", and "Let this program do whatever TB it wants.". There's only the choice of the program either not working at all or putting complete and utter trust into it, which is useless security theater. Of course everyone is just going to click "OK"; what else is there to do? If they are opening the program, they have already decided they want to use it, and there's no way at all to find out what that program needs the permission for: Does it just want to install in a way to be accessible to all users, or does it want to install a root kit and keylogger? WhoTF knows?

The way permissions are implemented in browsers and on phones on the other hand is IMHO the way to go: Whenever a program wants to do something requiring permissions it doesn't already have, the OS pops up a dialog "Do you want to allow this program to do X?" with options "Allow Once", "Deny Once", "Always Allow", "Always Deny". If you say no, the corresponding API call which triggered the dialog returns an error. Then have an OS feature to review / reset / configure permissions for each program.

Of course some compromise would have to be found between providing fine-grained control and not annoying the user every second, but if I could tell the difference between "this program wants to access the web cam" and "this program wants to install a kernel driver", that would already make the feature actually useful. To improve further, permissions could be organized in a hierarchy where you can choose which level of the hierarchy to allow, e. g. "Create files in this user-specific directory" < "Create files in all user-specific directories" < "Create files in user-specific and system directories" or whatever.

boomzilla

@pie_flavor said in So I decided to try to update part of my toolchain...:

@boomzilla said in So I decided to try to update part of my toolchain...:

@pie_flavor said in So I decided to try to update part of my toolchain...:

Also, apps needing to have uninstallers instead of using system-provided methods is TRWTF - no such thing is required in the UWP system.

I've been told this is all about anti-trust.

Standardized package system != standard repository location, and standard repository location != locked down to only that location (looking at you, Apple).

Yes, that's what I tried to get across to these numskulls.

hungrier

@ixvedeusi said in So I decided to try to update part of my toolchain...:

The main problem with UAC (and sudo) is that there's only two modes "don't let this program do anything at all", and "Let this program do whatever TB it wants.".

Or there's the third option where the program is coded sanely (), doesn't do anything silly like writing to system directories, and works fine without elevation.

dkf

@ixvedeusi The complexity is establishing the exact security profile, both in terms of what the capabilities should be (this isn't actually right on phones yet) and also in terms of explaining to users why they should or shouldn't grant the request.

HardwareGeek

@dkf said in So I decided to try to update part of my toolchain...:

@HardwareGeek said in So I decided to try to update part of my toolchain...:

However, there was a maximum length that was guaranteed to be significant.

Wouldn't that be a minimum length? After all, compilers and other related tools are free to consider more characters than the standard requires.

I suppose that depends on your viewpoint. From the compiler's viewpoint, yes, at least that many characters must be significant. From the user's viewpoint, that's the most you can rely on being significant.

Gąska

@hungrier said in So I decided to try to update part of my toolchain...:

@ixvedeusi said in So I decided to try to update part of my toolchain...:

The main problem with UAC (and sudo) is that there's only two modes "don't let this program do anything at all", and "Let this program do whatever TB it wants.".

Or there's the third option where the program is coded sanely (), doesn't do anything silly like writing to system directories, and works fine without elevation.

It's not hard to do when almost nothing is actually protected on the computer.

acrow

@Gąska said in So I decided to try to update part of my toolchain...:

@hungrier said in So I decided to try to update part of my toolchain...:

@ixvedeusi said in So I decided to try to update part of my toolchain...:

The main problem with UAC (and sudo) is that there's only two modes "don't let this program do anything at all", and "Let this program do whatever TB it wants.".

Or there's the third option where the program is coded sanely (), doesn't do anything silly like writing to system directories, and works fine without elevation.

It's not hard to do when almost nothing is actually protected on the computer.

There's little to protect on a consumer PC. In most cases, protecting the Firefox executable and the certificate storage suffices, as those are used for banking. Other information is generally too fragmented to reliably monetize. Unlike phones.

But if I could, I would want to be able to deny access to the Documents folder for most programs.

CodeJunkie

@Groaner said in So I decided to try to update part of my toolchain...:

Not me! I've been in the Windows world my entire career and I have yet to encounter anyone lamenting not being able to have 02132019 Annual Report.docx and 02132019 Annual report.docx in the same folder. It's almost like they understand that such an arrangement would be confusing! But *nix users and developers not understanding Windows is not a new thing, and vice versa.

What *nix users and developers don't seem to understand is that case sensitivity is just lazy development. It also further proves the hostility the devs have towards their users in general. Of course, it's now been that way for so long it's part of the *nix religion.

Edit: In other words none of them will ever admit that is was kind of a bad idea.

Gąska

@acrow said in So I decided to try to update part of my toolchain...:

@Gąska said in So I decided to try to update part of my toolchain...:

@hungrier said in So I decided to try to update part of my toolchain...:

@ixvedeusi said in So I decided to try to update part of my toolchain...:

The main problem with UAC (and sudo) is that there's only two modes "don't let this program do anything at all", and "Let this program do whatever TB it wants.".

Or there's the third option where the program is coded sanely (), doesn't do anything silly like writing to system directories, and works fine without elevation.

It's not hard to do when almost nothing is actually protected on the computer.

There's little to protect on a consumer PC.

In most cases, protecting the Firefox executable and the certificate storage suffices, as those are used for banking. Other information is generally too fragmented to reliably monetize.

Both Chrome and Firefox are very reliable in storing every single bit of sensitive information there is in a single folder that's freely accessible to every process you run.

But if I could, I would want to be able to deny access to the Documents folder for most programs.

And AppData. Definitely AppData. Not their AppData, of course. But definitely all not-their AppData.

acrow

@Gąska said in So I decided to try to update part of my toolchain...:

@acrow said in So I decided to try to update part of my toolchain...:

In most cases, protecting the Firefox executable and the certificate storage suffices, as those are used for banking. Other information is generally too fragmented to reliably monetize.

Both Chrome and Firefox are very reliable in storing every single bit of sensitive information there is in a single folder that's freely accessible to every process you run.

Fat lot of good it does them. Of three the banks that I use, 2 verify with a single-use password list, and one uses a token-generator device (though they have been bugging me to install an app instead). None of these banks use e-mail password recovery or similar jokes. I have no credit in any store whatsoever, so no easy monetization unless browser is thwarted. In that sense, the comic is a bit off; banking via browser is behind the admin account (or the browser binary is, anyway).

And AppData. Definitely AppData. Not their AppData, of course. But definitely all not-their AppData.

Agreed.

Gąska

@acrow said in So I decided to try to update part of my toolchain...:

@Gąska said in So I decided to try to update part of my toolchain...:

@acrow said in So I decided to try to update part of my toolchain...:

In most cases, protecting the Firefox executable and the certificate storage suffices, as those are used for banking. Other information is generally too fragmented to reliably monetize.

Both Chrome and Firefox are very reliable in storing every single bit of sensitive information there is in a single folder that's freely accessible to every process you run.

Fat lot of good it does them. Of three the banks that I use, 2 verify with a single-use password list, and one uses a token-generator device (though they have been bugging me to install an app instead). None of these banks use e-mail password recovery or similar jokes. I have no credit in any store whatsoever, so no easy monetization unless browser is thwarted.

Banking isn't the only thing you want to protect. And theft isn't the only bad thing that can happen to your data.

In that sense, the comic is a bit off; banking via browser is behind the admin account (or the browser binary is, anyway).

On Windows, you can install most process-level hooks without admin privileges.

dkf

@HardwareGeek said in So I decided to try to update part of my toolchain...:

From the user's viewpoint, that's the most you can rely on being significant.

I think you'll find that almost everyone implements higher limits. Except for one three-letter company in backward compatibility mode for some old systems that are ports of stuff that dates back to the 1950s.

marczellm

@Groaner said in So I decided to try to update part of my toolchain...:

what's the deal with the Hungarian prefix m? Didn't that antipattern die out a good decade and a half ago? I can tell if a variable is a member or not by mousing over it and looking at what Intellisense tells me.

We're doing that (not full Hungarian notation, just the mField thing) at my current workplace. Xcode doesn't tell you anything on mouse hover unless you're currently running the code in a debugger, and then it tells you its current value but not whether it's a member.

dkf

@marczellm said in So I decided to try to update part of my toolchain...:

We're doing that (not full Hungarian notation, just the mField thing) at my current workplace. Xcode doesn't tell you anything on mouse hover unless you're currently running the code in a debugger, and then it tells you its current value but not whether it's a member.

The Objective-C (and presumably Swift) object model allows for the interception of arbitrary methods by generic handlers; just because the method isn't declared in the class doesn't mean that you can't use it. I can see the plus sides of this (among other things, it's very much towards the original conception of OO) but, boy!, can it be abused…

Groaner

@marczellm said in So I decided to try to update part of my toolchain...:

We're doing that (not full Hungarian notation, just the mField thing) at my current workplace. Xcode doesn't tell you anything on mouse hover unless you're currently running the code in a debugger, and then it tells you its current value but not whether it's a member.

My sympathies. This is what I see when I mouse hover outside of a debug session:

And if that's not enough...

You can view the definition in context without leaving the spot you're working on!

pie_flavor

@acrow No, it doesn't. Does the concept of services and drivers and COM in general prevent new concepts and technologies by default? In order to extend the OS, the OS must provide an extension API. News at 11.

pie_flavor

@acrow said in So I decided to try to update part of my toolchain...:

@pie_flavor said in So I decided to try to update part of my toolchain...:

@dkf said in So I decided to try to update part of my toolchain...:

OTOH, merely having the creator of a file go away shouldn't delete the files created by that program. Deleting a user's pictures just because they deleted the photo editor they were using at one point is a bad plan!

And so you'd also set a type field, to mark it as a document, program file, user configuration file, program configuration file, etc.

Why stop there? We could collect all the configurations into a single place. That way, we can make sure that they're never accidentally altered, deleted or corrupted. Let's call it... uhh... a Registry!

The registry is global configuration though. I'm talking about per-file configuration.

Gąska

@levicki said in So I decided to try to update part of my toolchain...:

@ixvedeusi said in So I decided to try to update part of my toolchain...:

The main problem with UAC...

Is that it doesn't ask for credentials of the logged in user thus making its whole existence pointless. Anyone can come up to unlocked PC, run their nefarious program and click Yes.

This is not the problem UAC is trying to solve. Stop judging software solutions by how well they handle use cases they were never designed for.

pie_flavor

@Gąska Not only that but it's not even true - you can configure it to ask for a password every time.

JBert

@levicki said in So I decided to try to update part of my toolchain...:

@acrow said in So I decided to try to update part of my toolchain...:

No, a program does not really care about file- or folder paths. It cares about the string identifier (or URI) of that file.

Which is what URI is -- path + name + extension.

Change any of those and programs can no longer access the file contents.

The alternative is a multitude of lists of file-IDs, pointed to by other lists of file-IDs... and you're back in the folder structure again.

The alternative is a GUID for each file and the path of the file converted to tags.

C:\Documents\Reports\2018\Annual report

Would be represented as:
GUID: {CFA7C590-1B1B-43F4-B3A3-19307FDE3B2A}

Depth,Part
1,C
2,Documents
3,Reports
4,2018
5,Annual report
Renaming the file would be simply replacing some (or all) of those tags while physical blocks would not move at all and as far as filesystem is concerned all files would be at depth 1.

In other words, no folders and associated on-disk structures which complicate filesystem updates, notifications and search would need to exist at all.

The only hierarchy would thus be virtual representation to the user for the sake of familiarity.

if all files only had a UUID, you couldn't easily figure out which files were left behind by a bad un-installer for a crappy app.

If those files were dropped to C:\Windows\System32 or into sxs good luck figuring that out now.

On the other hand with GUIDs it would be easier to make installer operations transactional. You could mandate that they call an API fsStartInstall() and fsEndInstall() (the latter called automatically upon process termination if they "forget" to call it from all failure modes). Then the filesystem itself would know which files belong to what installation (it would have a list of GUIDs) and they could be later removed even if they were renamed and you would not need separate uninstaller for each application at all -- it would be an OS feature much like dragging an application into the trash on Mac.

BTW: Have you ever heard of an inode's serial number or NTFS' $Object_Id?

From Raymond Chen's blog (the latter link - emphasis mine):

So Igor's dream world where all files are referenced by GUID already exists. Why isn't everybody switching over to this utopia of GUID-based file identification?

You probably know the answer already: Because people prefer to name things with something mnemonic rather than a GUID. Imagine a file open dialog in this dream world. "Enter the GUID of the file you wish to open, or click Browse to see the GUIDs of all the files on this volume so you can pick from a list." How long would this dialog survive?

For today, you don't have to call me Raymond. You can call me {7ecf65a0-4b78-5f9b-e77c-8770091c0100}, or "91c" for short.

Gąska

@JBert (actually, Raymond Chen) said in So I decided to try to update part of my toolchain...:

Why isn't everybody switching over to this utopia of GUID-based file identification?
You probably know the answer already: Because

...no one actually tried to implement it in a sane way, which is absolutely possible, just a little tricky and would break all backward compatibility. It has nothing to do with GUIDs being hard to type - I mean, IPv6 is hard to type too, but you don't hear many people complaining about it whenever they want to connect to IPv6 sites. This is because you as the user don't need to know IPv6 to connect to a given IPv6. Similarly, if anyone ever made UID-based file access API (because it's not about filesystems - it's about OS-level API), it is absolutely guaranteed that the users wouldn't have to type in any UIDs themselves either - exactly because it's hard, error-prone and retarded.

Gąska

@levicki said in So I decided to try to update part of my toolchain...:

Also, extensions were supposed to be replaced with mime type which would be stored with GUID and used to convey the file type to the user. User would not be able to change mime type directly through user interface, but many programs would be able to register as capable of opening said mime type and user would be able to set the default program for each mime type.

Downvote. There are many reasons why someone would want to change file type. It's especially common (but not exclusive by any means) for plaintext formats, of which there are millions, and there are many workflows which rely on ability of changing types of random files because one program insists on putting its own extension/file type on a file it produces and another only allows files of a different extension/type as input.

Files sent in email as attachments would have to have correct mime type specified so you couldn't send text/plain attachment with .txt.exe extension and trick the user to run it because there would be no extension and the actual mime type specified would define what you can do with the file.

It would only work as long as every email server in the world set up MIME types correctly, and preserve them exactly all the way from sender to recipient. It's one thing to rely on one system doing the right thing every time - it's another to rely on the entire world doing the same.

acrow

@pie_flavor said in So I decided to try to update part of my toolchain...:

@acrow said in So I decided to try to update part of my toolchain...:

@pie_flavor said in So I decided to try to update part of my toolchain...:

@dkf said in So I decided to try to update part of my toolchain...:

OTOH, merely having the creator of a file go away shouldn't delete the files created by that program. Deleting a user's pictures just because they deleted the photo editor they were using at one point is a bad plan!

And so you'd also set a type field, to mark it as a document, program file, user configuration file, program configuration file, etc.

Why stop there? We could collect all the configurations into a single place. That way, we can make sure that they're never accidentally altered, deleted or corrupted. Let's call it... uhh... a Registry!

The registry is global configuration though. I'm talking about per-file configuration.

I know.

But I'm wondering now if storing those in a database, instead of in the file's node, would bring more benefits or risks. I mean, searchability and all...?

acrow

@pie_flavor said in So I decided to try to update part of my toolchain...:

@acrow No, it doesn't. Does the concept of services and drivers and COM in general prevent new concepts and technologies by default? In order to extend the OS, the OS must provide an extension API. News at 11.

Does the COM wall a garden now?

acrow

@levicki said in So I decided to try to update part of my toolchain...:

@acrow said in So I decided to try to update part of my toolchain...:

No, a program does not really care about file- or folder paths. It cares about the string identifier (or URI) of that file.

Which is what URI is -- path + name + extension.

Change any of those and programs can no longer access the file contents.

Yes. Exactly as designed. What's your point?

And, you know, there are more instances that I've wanted a program to not find a specific file or folder than the reverse.

The alternative is a multitude of lists of file-IDs, pointed to by other lists of file-IDs... and you're back in the folder structure again.

The alternative is a GUID for each file and the path of the file converted to tags.

C:\Documents\Reports\2018\Annual report

Would be represented as:
GUID: {CFA7C590-1B1B-43F4-B3A3-19307FDE3B2A}

Depth,Part
1,C
2,Documents
3,Reports
4,2018
5,Annual report
Renaming the file would be simply replacing some (or all) of those tags while physical blocks would not move at all and as far as filesystem is concerned all files would be at depth 1.

In other words, no folders and associated on-disk structures which complicate filesystem updates, notifications and search would need to exist at all.

The only hierarchy would thus be virtual representation to the user for the sake of familiarity.

Sounds to me like the amount of metadata would explode.

if all files only had a UUID, you couldn't easily figure out which files were left behind by a bad un-installer for a crappy app.

If those files were dropped to C:\Windows\System32 or into sxs good luck figuring that out now.

On the other hand with GUIDs it would be easier to make installer operations transactional. You could mandate that they call an API fsStartInstall() and fsEndInstall() (the latter called automatically upon process termination if they "forget" to call it from all failure modes). Then the filesystem itself would know which files belong to what installation (it would have a list of GUIDs) and they could be later removed even if they were renamed and you would not need separate uninstaller for each application at all -- it would be an OS feature much like dragging an application into the trash on Mac.

Unless the (un)installation affects other programs installed on the machine.

Gribnit

@levicki All filesystems I am aware of already employ sufficient indirection that renaming files does not involve physically moving the data. What you have here is the notion of an inode, but with GUIDs.

JBert

@Gąska said in So I decided to try to update part of my toolchain...:

@JBert (actually, Raymond Chen) said in So I decided to try to update part of my toolchain...:

Why isn't everybody switching over to this utopia of GUID-based file identification?
You probably know the answer already: Because

...no one actually tried to implement it in a sane way, which is absolutely possible, just a little tricky and would break all backward compatibility. It has nothing to do with GUIDs being hard to type - I mean, IPv6 is hard to type too, but you don't hear many people complaining about it whenever they want to connect to IPv6 sites. This is because you as the user don't need to know IPv6 to connect to a given IPv6. Similarly, if anyone ever made UID-based file access API (because it's not about filesystems - it's about OS-level API), it is absolutely guaranteed that the users wouldn't have to type in any UIDs themselves either - exactly because it's hard, error-prone and retarded.

I thought the reason we haven't seen IPv6 dialogs is because nobody is using IPv6.

Gąska

@Gribnit said in So I decided to try to update part of my toolchain...:

@levicki All filesystems I am aware of already employ sufficient indirection that renaming files does not involve physically moving the data. What you have here is the notion of an inode, but with GUIDs.

As I said previously, the problem isn't with filesystems - the problem is with OS-level APIs.