So I decided to try to update part of my toolchain...
-
@levicki said in So I decided to try to update part of my toolchain...:
I suggested that GUIDs be used as a unique key to identify a file which can have any name, even if many files have exactly the same name.
: Hey user, pick a file from this directory. I have:FileName1.txt (00109aca-a651-48e5-b7a1-961fa676bdc2) FileName1.txt (ad58f4ee-04a7-4cce-af62-0ccdffd87261) FileName1.txt (38958ef9-a558-47de-836c-a1ff2a2b8c89) FileName1.txt (3fcf98c5-1679-436d-9e03-5c9ca4a9855c) FileName1.txt (1e01116a-da6c-4d80-91fa-dd53f34fbc1e) FileName1.txt (5ef7b33e-90a4-4185-bbbc-f33e6228e7b8) FileName1.txt (85b6db8d-876c-4e90-8ea2-704ae37a7226)
-
@levicki said in So I decided to try to update part of my toolchain...:
Why do we insist on the file name to be the unique identifier of the file when it is crystal clear that is both wrong and impossible?
Why don't you name all your children "Charlie". Because the unique identifier of each (DNA) makes it crystal clear who is who.
-
@levicki So, let's say I should like to see a particular file in ~/.ssh. Would that be the same guid everywhere?
-
@dcon said in So I decided to try to update part of my toolchain...:
@levicki said in So I decided to try to update part of my toolchain...:
I suggested that GUIDs be used as a unique key to identify a file which can have any name, even if many files have exactly the same name.
: Hey user, pick a file from this directory. I have:FileName1.txt (00109aca-a651-48e5-b7a1-961fa676bdc2) FileName1.txt (ad58f4ee-04a7-4cce-af62-0ccdffd87261) FileName1.txt (38958ef9-a558-47de-836c-a1ff2a2b8c89) FileName1.txt (3fcf98c5-1679-436d-9e03-5c9ca4a9855c) FileName1.txt (1e01116a-da6c-4d80-91fa-dd53f34fbc1e) FileName1.txt (5ef7b33e-90a4-4185-bbbc-f33e6228e7b8) FileName1.txt (85b6db8d-876c-4e90-8ea2-704ae37a7226)Minus .txt, since the new file system uses embedded MIME types instead of extensions. But anyway, it's the user's fault if they can't tell them apart. Maybe they can, based on the icon, or based on the file type, or based on the physical position in the list. If it showed desktop files the way they actually appear on the desktop, instead of a list structure for no reason, I'd know exactly which file was which.
-
@Gribnit Another metadata field, corresponding to constant files. It'd have two GUIDs, one being actually unique and one corresponding to its recognizability.
-
@dcon said in So I decided to try to update part of my toolchain...:
@levicki said in So I decided to try to update part of my toolchain...:
I suggested that GUIDs be used as a unique key to identify a file which can have any name, even if many files have exactly the same name.
: Hey user, pick a file from this directory. I have:FileName1.txt (00109aca-a651-48e5-b7a1-961fa676bdc2) FileName1.txt (ad58f4ee-04a7-4cce-af62-0ccdffd87261) FileName1.txt (38958ef9-a558-47de-836c-a1ff2a2b8c89) FileName1.txt (3fcf98c5-1679-436d-9e03-5c9ca4a9855c) FileName1.txt (1e01116a-da6c-4d80-91fa-dd53f34fbc1e) FileName1.txt (5ef7b33e-90a4-4185-bbbc-f33e6228e7b8) FileName1.txt (85b6db8d-876c-4e90-8ea2-704ae37a7226)This is what Google Drive already does, except you don't see the unique IDs, you just see files with identical names and possibly different modified dates. If they are Google Docs, you can't compare them easily for differences...
-
@LB_ I wonder what happens when you synchronize them to PC.
-
@GÄ…ska It appears it renames your files... silently...
-
@levicki Tell me something though. Why should some program be able to find files after they are renamed or moved? If they are a user's files, e.g. photos or documents, the user will point the program to the files he wishes to open anyways. And if the files belong to the program, they're hidden in the AppData (or similar) folder, out of the way of the user and not moving around by themselves. So, where's the use-case?
Also, a file database can be made with inodes instead of UIDs as the reference, so why add an extra step that slows stepping through a folder?
-
@acrow said in So I decided to try to update part of my toolchain...:
why add an extra step that slows
I don't think you have been paying enough attention to this thing called, if somewhat mistakenly, software devlopment.
-
@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...:
@levicki said in So I decided to try to update part of my toolchain...:
I suggested that GUIDs be used as a unique key to identify a file which can have any name, even if many files have exactly the same name.
: Hey user, pick a file from this directory. I have:FileName1.txt (00109aca-a651-48e5-b7a1-961fa676bdc2) FileName1.txt (ad58f4ee-04a7-4cce-af62-0ccdffd87261) FileName1.txt (38958ef9-a558-47de-836c-a1ff2a2b8c89) FileName1.txt (3fcf98c5-1679-436d-9e03-5c9ca4a9855c) FileName1.txt (1e01116a-da6c-4d80-91fa-dd53f34fbc1e) FileName1.txt (5ef7b33e-90a4-4185-bbbc-f33e6228e7b8) FileName1.txt (85b6db8d-876c-4e90-8ea2-704ae37a7226)Minus .txt, since the new file system uses embedded MIME types instead of extensions. But anyway, it's the user's fault if they can't tell them apart. Maybe they can, based on the icon, or based on the file type, or based on the physical position in the list. If it showed desktop files the way they actually appear on the desktop, instead of a list structure for no reason, I'd know exactly which file was which.
Hey, I just add ".txt" to all my files. I didn't say they were text!
-
@GÄ…ska said in So I decided to try to update part of my toolchain...:
@LB_ I wonder what happens when you synchronize them to PC.
It gives them distinct names on the filesystem but they keep their identical names on the web view.
-
@acrow said in So I decided to try to update part of my toolchain...:
@levicki Tell me something though. Why should some program be able to find files after they are renamed or moved? If they are a user's files, e.g. photos or documents, the user will point the program to the files he wishes to open anyways. And if the files belong to the program, they're hidden in the AppData (or similar) folder, out of the way of the user and not moving around by themselves. So, where's the use-case?
Also, a file database can be made with inodes instead of UIDs as the reference, so why add an extra step that slows stepping through a folder?
Wat? You're saying 'the user will fix the brokenness and do extra legwork anyway, why bother being useful?'
-
I am reminded of something Jeff said about trees.
-
@acrow said in So I decided to try to update part of my toolchain...:
@levicki Tell me something though. Why should some program be able to find files after they are renamed or moved? If they are a user's files, e.g. photos or documents, the user will point the program to the files he wishes to open anyways. And if the files belong to the program, they're hidden in the AppData (or similar) folder, out of the way of the user and not moving around by themselves. So, where's the use-case?
It was considered a very important feature by the users of a desktop publishing application I worked on a while ago. A complex layout document could have hundreds or thousands of placed files, so keeping the number of moved or renamed files needing relinking to a minimum was big for production speed.
On the Classic MacOS, when using local volumes or Mac-based servers, this worked fairly well without any work from us. Mac file references pick up changes for free in most cases, so users could manage their files however they want with very little fixing of file references.
Unfortunately, some servers offering MacOS file sharing were buggy and didn't always keep the references properly, so they could break unexpectedly or start pointing to an entirely different file. We were getting reports of this while we were also rewriting our program to be multiplatform. I ended up writing a small set of file reference management classes to add some resilience to file locations, even when the document came from a different platform. We also started keeping more info about the file itself so we could match it based on file size and type, regardless of name. Lastly, the Mac folks added an option to force files on servers to match all of the file info we kept, not just the reference.
So we did a lot of work to keep what the MacOS had even when using buggy servers and add a bit of that utility to Windows and Linux.
-
@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...:
@levicki Tell me something though. Why should some program be able to find files after they are renamed or moved? If they are a user's files, e.g. photos or documents, the user will point the program to the files he wishes to open anyways. And if the files belong to the program, they're hidden in the AppData (or similar) folder, out of the way of the user and not moving around by themselves. So, where's the use-case?
Also, a file database can be made with inodes instead of UIDs as the reference, so why add an extra step that slows stepping through a folder?
Wat? You're saying 'the user will fix the brokenness and do extra legwork anyway, why bother being useful?'
No, I'm saying that if the user only has access to his own files, he can only mess up his own files. If he accidentally messes up his own files, he should be told of it as soon as possible, instad of limping on.
We've already seen servers getting misplaced. Still functional, but nobody knows where it is or how to get hold of it. Would this phenomenon then not happen with files? Imagine the support call: "Your software can open my file, but I can't find it. Haw can I get your software to tell me where my file is?"
Also, imagine if files were opening just fine after they've been moved to Recycle Bin (or equivalent). The action that caused them to be mopved there would be covered up by everything working as normal, all the way until disk space is low and garbage colection occurs. Extreme example, but I'm sure you can imagine similar cases.
-
@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...:
Tell me something though. Why should some program be able to find files after they are renamed or moved?
Why not? Would you prefer your boot failing because windows can't find winboot.exe which was moved by the user or malware or windows referring to that file by GUID and thus being able to find it at all times?
Yes, because it'd make the proble immediately apparent, instead of festering. If it's a virus, non-booting means it will not get my banking credentials. If it was user action, the lesson is hammered home now instead of next Windows update, when it would be blamed on Microsoft.
-
@Parody 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...:
@levicki Tell me something though. Why should some program be able to find files after they are renamed or moved? If they are a user's files, e.g. photos or documents, the user will point the program to the files he wishes to open anyways. And if the files belong to the program, they're hidden in the AppData (or similar) folder, out of the way of the user and not moving around by themselves. So, where's the use-case?
It was considered a very important feature by the users of a desktop publishing application I worked on a while ago. A complex layout document could have hundreds or thousands of placed files, so keeping the number of moved or renamed files needing relinking to a minimum was big for production speed.
On the Classic MacOS, when using local volumes or Mac-based servers, this worked fairly well without any work from us. Mac file references pick up changes for free in most cases, so users could manage their files however they want with very little fixing of file references.
Unfortunately, some servers offering MacOS file sharing were buggy and didn't always keep the references properly, so they could break unexpectedly or start pointing to an entirely different file. We were getting reports of this while we were also rewriting our program to be multiplatform. I ended up writing a small set of file reference management classes to add some resilience to file locations, even when the document came from a different platform. We also started keeping more info about the file itself so we could match it based on file size and type, regardless of name. Lastly, the Mac folks added an option to force files on servers to match all of the file info we kept, not just the reference.
So we did a lot of work to keep what the MacOS had even when using buggy servers and add a bit of that utility to Windows and Linux.
Okay. That use-case I can understand.
But it still brings 2 questions:
- You didn't consider checksumming the files? Or just didn't mention? If I had to programmatically hunt for misplaced files like that, I'd keep an md5 reference.
- No dedicated resource-management tools?
Of course, I assume that most of the didn't change, but were just moved around.
-
@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...:
@acrow said in So I decided to try to update part of my toolchain...:
@levicki Tell me something though. Why should some program be able to find files after they are renamed or moved? If they are a user's files, e.g. photos or documents, the user will point the program to the files he wishes to open anyways. And if the files belong to the program, they're hidden in the AppData (or similar) folder, out of the way of the user and not moving around by themselves. So, where's the use-case?
Also, a file database can be made with inodes instead of UIDs as the reference, so why add an extra step that slows stepping through a folder?
Wat? You're saying 'the user will fix the brokenness and do extra legwork anyway, why bother being useful?'
No, I'm saying that if the user only has access to his own files, he can only mess up his own files. If he accidentally messes up his own files, he should be told of it as soon as possible, instad of limping on.
Right, but you're the one calling moving or renaming files 'messing up' files.
We've already seen servers getting misplaced. Still functional, but nobody knows where it is or how to get hold of it. Would this phenomenon then not happen with files? Imagine the support call: "Your software can open my file, but I can't find it. Haw can I get your software to tell me where my file is?"
Given the GUID of a file, the OS can find the name and path of a file.
Also, imagine if files were opening just fine after they've been moved to Recycle Bin (or equivalent). The action that caused them to be mopved there would be covered up by everything working as normal, all the way until disk space is low and garbage colection occurs. Extreme example, but I'm sure you can imagine similar cases.
Only if you consider the Recycle Bin just another place to move files to. You're acting like files opening fine there would be a fault of the file system and not the Recycle Bin implementation.
-
@pie_flavor said in So I decided to try to update part of my toolchain...:
We've already seen servers getting misplaced. Still functional, but nobody knows where it is or how to get hold of it. Would this phenomenon then not happen with files? Imagine the support call: "Your software can open my file, but I can't find it. Haw can I get your software to tell me where my file is?"
Given the GUID of a file, the OS can find the name and path of a file.
So, new software developmet guidelines: "Every program that remembers and opens a file on startup MUST display that file's GUID. Also, any Recently User Files listing MUST display GUID or current path."
-
@acrow Why on startup? What's special about on startup? And why should GUIDs get shown to the end user?
-
@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...:
@acrow said in So I decided to try to update part of my toolchain...:
@levicki Tell me something though. Why should some program be able to find files after they are renamed or moved? If they are a user's files, e.g. photos or documents, the user will point the program to the files he wishes to open anyways. And if the files belong to the program, they're hidden in the AppData (or similar) folder, out of the way of the user and not moving around by themselves. So, where's the use-case?
Also, a file database can be made with inodes instead of UIDs as the reference, so why add an extra step that slows stepping through a folder?
Wat? You're saying 'the user will fix the brokenness and do extra legwork anyway, why bother being useful?'
No, I'm saying that if the user only has access to his own files, he can only mess up his own files. If he accidentally messes up his own files, he should be told of it as soon as possible, instad of limping on.
What exactly does renaming mess up?
We've already seen servers getting misplaced. Still functional, but nobody knows where it is or how to get hold of it. Would this phenomenon then not happen with files?
Not only it will, but it already does all the time right now with our current name-and-path-based approach.
Imagine the support call: "Your software can open my file, but I can't find it. Haw can I get your software to tell me where my file is?"
I have a hard time imagining what could have possibly caused:
- The user knowing about the file;
- The program opening the file;
- The user doing something with the file;
- The user not knowing anymore where the file went;
- The user still being able to use the program to open the file.
It's the equivalent of "and what if a war breaks out tomorrow and our town gets hit by a nuke? Would people still have access to non-GMO vegetables?"
Also, imagine if files were opening just fine after they've been moved to Recycle Bin (or equivalent). The action that caused them to be mopved there would be covered up by everything working as normal, all the way until disk space is low and garbage colection occurs. Extreme example, but I'm sure you can imagine similar cases.
Your hypothetical scenarios get more and more bizarre, and the system features required to support them get more and more retarded. You've crossed the "no one would ever implement anything like that" line long ago.
-
@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...:
We've already seen servers getting misplaced. Still functional, but nobody knows where it is or how to get hold of it. Would this phenomenon then not happen with files? Imagine the support call: "Your software can open my file, but I can't find it. Haw can I get your software to tell me where my file is?"
Given the GUID of a file, the OS can find the name and path of a file.
So, new software developmet guidelines: "Every program that remembers and opens a file on startup MUST display that file's GUID. Also, any Recently User Files listing MUST display GUID or current path."
But why? What problem does it solve?
-
@GÄ…ska said in So I decided to try to update part of my toolchain...:
What problem does it solve?
The shortage of straw men.
-
@pie_flavor said in So I decided to try to update part of my toolchain...:
@acrow Why on startup? What's special about on startup?
I meant when the software is started. A lot of apps open automatically whatever document you had open when last closing the app.
And why should GUIDs get shown to the end user?
Because:
@pie_flavor said in So I decided to try to update part of my toolchain...:
Given the GUID of a file, the OS can find the name and path of a file.
So, now the app has a file open, but the user has no idea how to get a hold of that file. You state that they only need to get the GUID. Okay, so how does the user get the GUID out of a random app then?
-
@GÄ…ska said in So I decided to try to update part of my toolchain...:
I have a hard time imagining what could have possibly caused:
- The user knowing about the file;
- The program opening the file;
- The user doing something with the file;
3.5 The user losing the file while "cleaning".
- The user not knowing anymore where the file went;
- The user still being able to use the program to open the file.
Isn't that the whole point of this hypothetical GUID-based filesystem? That program still finds the file based on the GUID, even though the user lost it.
If not, then what point was there in said hypothetical GUID-based filesystem?
-
@acrow said in So I decided to try to update part of my toolchain...:
Isn't that the whole point of this hypothetical GUID-based filesystem? That program still finds the file based on the GUID, even though the user lost it.
No, the point is to get rid of all string manipulation that's currently required to access/manipulate files programmatically. Ideally, user experience should stay the same.
-
@levicki said in So I decided to try to update part of my toolchain...:
Also without folders in a classical sense (as a filesystem tree structure), the access would be faster because physically all files on disk would be in the same folder. On-disk tree structure would become virtual (move code/complexity to file manager).
Um... you realize that filesystems have already been doing exactly that for almost(?) two decades already?
-
@GÄ…ska said in So I decided to try to update part of my toolchain...:
Um... you realize that filesystems have already been doing exactly that for almost(?) two decades already?
Even further, IIRC.
-
@acrow said in So I decided to try to update part of my toolchain...:
And why should GUIDs get shown to the end user?
Because:
@pie_flavor said in So I decided to try to update part of my toolchain...:
Given the GUID of a file, the OS can find the name and path of a file.
So, now the app has a file open, but the user has no idea how to get a hold of that file. You state that they only need to get the GUID. Okay, so how does the user get the GUID out of a random app then?
Why does the user need the GUID? The app has the GUID; the app knows where the file is; the app tells the user where the file is.
-
@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...:
Isn't that the whole point of this hypothetical GUID-based filesystem? That program still finds the file based on the GUID, even though the user lost it.
No, the point is to get rid of all string manipulation that's currently required to access/manipulate files programmatically. Ideally, user experience should stay the same.
Okay. That's a reason I could go with.
But, dividing this to 2 scenarios:
-
If it's files in user's home folder, won't the user encounter the system behavior, stated earlier, where apps find files that the user has lost? Or, will the system behave as the user expects, if he renames a file "*.backup", copies it, and renames the copy to the original name? (This behavior has been seen in the wild.)
-
If it's files in an AppData or similar folder, how much would this really simplify file handling code, assuming that a) the OS has a proper OO file handling facility, and b) the software is written to use %APPDATA% instead of hard-coded paths?
-
-
@acrow said in So I decided to try to update part of my toolchain...:
the software is written to use %APPDATA% instead of hard-coded paths
-
@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...:
And why should GUIDs get shown to the end user?
Because:
@pie_flavor said in So I decided to try to update part of my toolchain...:
Given the GUID of a file, the OS can find the name and path of a file.
So, now the app has a file open, but the user has no idea how to get a hold of that file. You state that they only need to get the GUID. Okay, so how does the user get the GUID out of a random app then?
Why does the user need the GUID? The app has the GUID; the app knows where the file is; the app tells the user where the file is.
The app tells the user where the file is, IIF the app has been programmed to tell the user where the file is. I have seen apps that have e.g. a list of recently opened files, but no paths for them. Thus, do we mandate that all apps using this system must display the path of the opened file?
-
@dkf 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...:
the software is written to use %APPDATA% instead of hard-coded paths
What? I haven't written software for Windows without Qt, so I'm a bit hazy on the nomenclerature here. Qt just returns me a folder path to store machine-specific configuration files to, in a cross-platform way. They usually end up in AppData. So sue me.
-
@levicki said in So I decided to try to update part of my toolchain...:
(or inode or whatever you want to call it)
No, I meant this:
Also without folders in a classical sense (as a filesystem tree structure), the access would be faster because physically all files on disk would be in the same folder.
This would depend on the access pattern. In the current system, a reference to the folder's inode allows you to walk through the folder's contents in the fastest possible way. Since most software I use usually process a folder at a time (if accessing multiple files), this is the metric that matters to me. Your use-case is different, I guess.
-
@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...:
- If it's files in user's home folder, won't the user encounter the system behavior, stated earlier, where apps find files that the user has lost? Or, will the system behave as the user expects, if he renames a file "*.backup", copies it, and renames the copy to the original name? (This behavior has been seen in the wild.)
I can answer this scenario.
If you copy the file, the new copy will have a new GUID. Renaming it to the same name will not overwrite the old file because the name is not the unique identifier -- GUID is. In other words, system will allow you to have two files with the same name right next to each other.
Furthermore, you can use CoW optimization and just create a new GUID and associated metadata referring to the same physical file and make a physical copy only when the view of new file changes (i.e. when user opens it, makes changes, and tries to save).
Clarification. Imeant this scenario:
Starting point:
myfile (GUID1)State2:
myfile.backup (GUID1)State3:
myfile.backup (GUID1)
myfile.backup - Copy (GUID2)Last state:
myfile.backup (GUID1)
myfile (GUID2)And, I repeat, this is a user behavior that I have seen in the wild.
Anyways, in subsequent access, any software that uses GUID as the reference for <last opened file>, would access a different file than the user expects.
-
@acrow said in So I decided to try to update part of my toolchain...:
Anyways, in subsequent access, any software that uses GUID as the reference for <last opened file>, would access a different file than the user expects.
Do you mean a particular version of a file, or a file as a mutable object?
-
@levicki said in So I decided to try to update part of my toolchain...:
@acrow On this imaginary filesystem there would be no folders and thus no inodes for them. Only files with unique IDs and collections of tags which put those files in virtual hierarchy.
Yes, I know. My point was that there may not be speed gains for GUID + database vs. inodes in the general PC usage scenario. I do admit that there are gains to be had in several specialized fields.
-
@dkf 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...:
Anyways, in subsequent access, any software that uses GUID as the reference for <last opened file>, would access a different file than the user expects.
Do you mean a particular version of a file, or a file as a mutable object?
I mean that the user thinks he's opening file "myfile", when the app opens file "myfile.backup", and may not display this to the user. So... mutable object, I guess...?
-
@acrow said in So I decided to try to update part of my toolchain...:
- If it's files in user's home folder, won't the user encounter the system behavior, stated earlier, where apps find files that the user has lost? Or, will the system behave as the user expects, if he renames a file "*.backup", copies it, and renames the copy to the original name? (This behavior has been seen in the wild.)
What happens after rename is up to discussion. There are situations when keeping the same UID is okay, there are situations when making new one is better, and both designs can be made to work with UID-based file access layer (not to be confused with filesystem, and not to be confused with UI). As for restoring a file by naming it the same it was before - obviously it would be quite hard to implement that, and even worse, implementing it would defeat entire purpose of getting rid of textual labels as main file identifiers. So replicating UX exactly is not just very hard or even impossible, but also unwanted. We'd have to change the paradigm of how we think of files and data on disk. Hot-swapping random files inside program directory wouldn't be a thing, and neither would be reading config files from some predefined path. That sounds very crippling for the user, but remember one thing - it won't be just user that would have to adjust; program developers would have to adjust too. The rename-copy-restore use case only exists because paths and filenames are so important in our current paradigm. The entire situation just doesn't exist with UID-based files, just like proofs by contradiction don't exist when you don't assume the law of excluded middle (and there are branches of maths that have a very good reason not to). Whatever you were trying to achieve with that rename dance, could be done different way (provided appropriate interfaces exist). There could be "backup file" action in file manager, and it would be stored in special directory from which you could later restore it with the same UID - kinda like recycle bin works today, except it wouldn't delete the original.
- If it's files in an AppData or similar folder, how much would this really simplify file handling code
The goal isn't to simplify anything. The goal is to increase security and reliability (especially reliability) of all software by enforcing good practices on all programs. But compared to current best practices with filename-and-path paradigm, things wouldn't really change much for good developers, except they won't have to work out themselves where the appropriate storage location is for their data.
-
@acrow 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...:
@acrow said in So I decided to try to update part of my toolchain...:
the software is written to use %APPDATA% instead of hard-coded paths
What? I haven't written software for Windows without Qt, so I'm a bit hazy on the nomenclerature here. Qt just returns me a folder path to store machine-specific configuration files to, in a cross-platform way. They usually end up in AppData. So sue me.
It's not nomenclature. It's that you seemingly believe that all developers are as knowledgeable and caring as you, and that nobody does stuff like hardcoding paths when they should've used AppData. When you're a good developer, the problem is (mostly) not with your code, but with someone else's code.
-
@acrow said in So I decided to try to update part of my toolchain...:
You didn't consider checksumming the files? Or just didn't mention? If I had to programmatically hunt for misplaced files like that, I'd keep an md5 reference.
We probably did keep some kind of CRC when we started keeping the other file data; I don't remember now. You don't have to read the entire file to dump out on file size and type, though.
(FWIW: the earliest MacOS-only versions of the application probably predated MD5.)
No dedicated resource-management tools?
File servers were pretty advanced resource management tools! :)
We did sell an image management system which would keep previews of your files, tell you which volume (local drive, server volume, floppy disk, removable cartridge hard drive, CD, tape...) they were on, and such. It never went cross-platform, though, and there were a number of competitors.
Of course, I assume that most of the didn't change, but were just moved around.
I think so, but renames happened often enough. Most changes were actually content changes, but those don't usually cause reference problems other than having to recalculate any file data we were keeping.
-
@GÄ…ska said in So I decided to try to update part of my toolchain...:
We'd have to change the paradigm of how we think of files and data on disk.
So, definitely not for general PC use by the masses, then, I believe. I may be wrong, but.. Some of my coworkers can't understand why version control software is better than a mess of folders named like project32#2_0_1. It's like "seeing is believing", and if they can't see the file icon, it doesn't exist.
@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...:
@dkf 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...:
the software is written to use %APPDATA% instead of hard-coded paths
What? I haven't written software for Windows without Qt, so I'm a bit hazy on the nomenclerature here. Qt just returns me a folder path to store machine-specific configuration files to, in a cross-platform way. They usually end up in AppData. So sue me.
It's not nomenclature. It's that you seemingly believe that all developers are as knowledgeable and caring as you, and that nobody does stuff like hardcoding paths when they should've used AppData. When you're a good developer, the problem is (mostly) not with your code, but with someone else's code.
When talking benefits of theoretical system architecture variations, I don't like to assume misuse. Comparing a theoretical system to an abused one, is like most discussions on communism; one-sided. Either compare them both perfectly implemented in theory, or compare them both abused.
Not applied when the topic is about battling abuse, and system changes to that purpose.
Edit:
P.S. Yes, I'm the real WTF for not assuming abuse on this forum.
-
@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...:
We'd have to change the paradigm of how we think of files and data on disk.
So, definitely not for general PC use by the masses, then, I believe.
Absolutely for general PC use by the masses. Android and iOS have both shown beyond any doubt that most users don't care about paths. And both those platforms are already halfway through with what I proposed.
@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...:
@dkf 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...:
the software is written to use %APPDATA% instead of hard-coded paths
What? I haven't written software for Windows without Qt, so I'm a bit hazy on the nomenclerature here. Qt just returns me a folder path to store machine-specific configuration files to, in a cross-platform way. They usually end up in AppData. So sue me.
It's not nomenclature. It's that you seemingly believe that all developers are as knowledgeable and caring as you, and that nobody does stuff like hardcoding paths when they should've used AppData. When you're a good developer, the problem is (mostly) not with your code, but with someone else's code.
When talking benefits of theoretical system architecture variations, I don't like to assume misuse. Comparing a theoretical system to an abused one, is like most discussions on communism; one-sided. Either compare them both perfectly implemented in theory, or compare them both abused.
Not applied when the topic is about battling abuse, and system changes to that purpose.
Well, I thought it's obvious we're talking about battling abuse. Because there's literally no other benefit to UID-based files than that it makes trashing the computer in various ways that are very common with path-based files, nearly impossible. Other than that, it literally gives you nothing. But the not trashing the computer thing is so incredibly huge that I think this alone is enough justification for why UID-based files are infinitely superior.
-
@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...:
@GÄ…ska said in So I decided to try to update part of my toolchain...:
We'd have to change the paradigm of how we think of files and data on disk.
So, definitely not for general PC use by the masses, then, I believe.
Absolutely for general PC use by the masses. Android and iOS have both shown beyond any doubt that most users don't care about paths. And both those platforms are already halfway through with what I proposed.
I guess I'm really the
for only looking at it from the PC-as-a-workstation angle.
I could argue that people don't handle quantities of files on entertainment phablets, but I'd likely lose. People take so many photos.I feel old now. What next? Windows SDKs are only published for Linux, as consumer-Windows gets too locked down and Enterprise Edition too expensive? </joke>
-
@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...:
@GÄ…ska said in So I decided to try to update part of my toolchain...:
We'd have to change the paradigm of how we think of files and data on disk.
So, definitely not for general PC use by the masses, then, I believe.
Absolutely for general PC use by the masses. Android and iOS have both shown beyond any doubt that most users don't care about paths. And both those platforms are already halfway through with what I proposed.
I guess I'm really the
for only looking at it from the PC-as-a-workstation angle.It can work for PC-as-a-workstations too. It just hasn't been tried yet. And it hasn't been tried mostly because of backward compatibility.
-
@acrow said in So I decided to try to update part of my toolchain...:
"Your software can open my file, but I can't find it. Haw can I get your software to tell me where my file is?"
Since I auto-open the last file, I already have users asking "how to I back up my data". (Sometimes I think auto-opening the last file was a bad idea...) I added a properties dialog that shows where the file is.
-
@levicki said in So I decided to try to update part of my toolchain...:
In other words, system will allow you to have two files with the same name right next to each other.
Which, when dealing with users, is the stupidest thing you can do.
Hmm. Do I want FileName or FileName.Now, instead of relying on the name of the file to identify which is current - now you have add some type of preview capability.
: Everyone, please send me your notes from the meeting.
: 42 new files are now in Shared.
: (looks, sees 42 copies of Notes)
-
@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...:
@dkf 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...:
the software is written to use %APPDATA% instead of hard-coded paths
What? I haven't written software for Windows without Qt, so I'm a bit hazy on the nomenclerature here. Qt just returns me a folder path to store machine-specific configuration files to, in a cross-platform way. They usually end up in AppData. So sue me.
It's not nomenclature. It's that you seemingly believe that all developers are as knowledgeable and caring as you, and that nobody does stuff like hardcoding paths when they should've used AppData. When you're a good developer, the problem is (mostly) not with your code, but with someone else's code.
Obviously, APPDATA is
C:\Documents and Settings\%USERPROFILE%\Application Data. AmIRight? (Ok, I had to actually turn on my XP VM to remember that path)
-
@dcon wrong. It's
C:\Documents and Settings\%USERPROFILE%\Dane aplikacji!
XFS - Wikipedia