I tried renaming a file in Ubuntu


  • Considered Harmful

    @blakeyrat said:

    @joe.edwards said:
    You'd find the same schism between self-driving and manually-driven car owners as you do between GUI junkies and CLI junkies.

    But if the track goes all the exact same places, most of them faster (some of them admittedly a little slower), why wouldn't you put your car on the track?

    Well, it might be safer, and easier, but you could only go where there was infrastructure set up already [only do tasks a GUI had been designed for]; but, more importantly, the open road represents freedom to a lot of people (especially eg bikers). Funny, there are also a class of computer users who never shut about freedom, and they seem to by and large overlap with the people who prefer the "hard to learn and dangerous" method of computer usage as well.

    Linux - and say Harley Davidson if we want to keep the analogy going forever - is targeted at a demographic of enthusiasts, who value freedom of choice over ease and safety. And I don't see anything wrong with that.



  • @gilhad said:

    @Salamander said:

    @flabdablet said:

    Reading system logs in Windows is slow, because Event Viewer sucks. Search them? Good luck with that, especially if the pattern you're searching for is complicated enough to need a regex to describe. Want to do a search and replace in the Registry because you're moving the root of the user profiles tree to a different drive? Good luck with that (hint: easiest way, using the tools supplied with the system, is to export the whole fucking Registry to a flat text file and do your search and replace with a text editor). Oh, I'm not supposed to touch the Registry because there's supposed to be a specialized GUI or some cunning COM API to do that specific task the Right Way instead? Good luck with tracking that down before lunch. And on and on and on.

    So the tools written for all that stuff happened to be rather shitty, therefore text-based configuration is superior?
    Does not follow.

     

    The point here is, that the graphical tools on Windows are shitty, or at leat too much limited.

    There is much larger range of tools for manipulating text and when the configuration/logs/events/whatever is text based, it can be managed by the (fast and powerfull) text manipulating tools.

    GUI tools are good for easy tasks. But if you have difficult task at hands and the author of GUI did not envisioned such task, then you have problem. With text data and text manipulating tools you have much large range of possible actions and you can solve much harder tasks with relative easiness.

     

    There is a middle way between GUI and raw text manipulation: a structured persistence layer (such as Windows Events logs) and a modern scripting language that can not only manipulated and deep-search objects but also format the output easily. Yes I'm talking about Powershell.



  • @blakeyrat said:

    What is actually the benefit of learning the Linux CLI? I would love to know.
     

    The Linux GUI tools are essentially creating CLI commands (well, API calls) to the underlying OS so a shitty Linux GUI tool tends to be overlooked in favour of the commands.

    The benefits in learning a command-driven front-end over graphical methods... well, there's studies as to the usefulness of PowerShell et al.

    @blakeyrat said:

    (The answer, though, I'm pretty sure is: "well you kind of have to, because Linux is so shitty that's literally the only way to do some things.")

    Peculiarly I was provided some PowerShell scripts because the GUI tools to manage SharePoint are fairly shitty and limited, and it seemed PS was the only way to do some things.

    @blakeyrat said:

    All I get out of Linux is doing the exact same things, but slower, and a different huge pain in the ass every week.

    I really think you've got a business case to drive forward a real change here. It seems you have 3 choices to present to your boss:

    1. employ someone who knows Linux commands to do the admin stuff. You direct them to what needs doing they work out the commands to do it. You need a geek that's willing to accept they may know all there is to know about firearms, but you're the one telling them what to shoot and when.
    2. invest time in learning Linux stuff - gain the know-how yourself. I'd advise against this completely; you already have prior baggage and it doesn't make any financial sense at all skilling you up to a level of capability that will be used occasionally. Buying in capability is a cheaper option.
    3. replace the *nix shite with something you can manage confidently and capably. If you're responsible for it, you should have a say in what methods you'll use to deliver business functionality. This could be an expensive one-off cost, but this way you'll get to properly design and implement something you know to be sound, rather than picking up someone's discarded half-efforts.
    You're in a shit position and I don't envy it. But unless you opt for one of those alternative routes, you're just prolonging the same plod down Frustration Street.


  • @Cassidy said:

    Peculiarly I was provided some PowerShell scripts because the GUI tools to manage SharePoint are fairly shitty and limited, and it seemed PS was the only way to do some things.
    Have you seen Exchange 2007 or newer? All the GUI tools do is run PowerShell commands in the background - and there are some things you can only do with PowerShell (and when you do some of these things in PowerShell, the GUI will only display a command line when you check what the setting does, and tell you to use the shell to modify it).



  • @flabdablet said:

    @Salamander said:
    @flabdablet said:

    The reason you'll see so many CLI-based solutions posted on Linux help forums is that it's far less time-consuming to write out three or four command lines and say "paste this into a terminal" than it is to do a full step-by-step GUI walkthrough with all necessary screenshots.

    Ah, so pure laziness. Gotcha.

    What you describe as "laziness", most system administrators and help desk operators would describe as "effective time management".

    Seconded. It's all of 3 seconds to copy and paste text from a window as opposed to having to take a screen shot, paste it into Paint, copy out the part of the image needed, then paste it into . . . whatever. If I need more text, I can copy and paste it all at the same time, then delete those parts I don't need. From a GUI interface, it's multiple screen captures, cut out the part I want, paste, rinse and repeat. For me, text/CLI is much faster and easier. It's not laziness by any stretch.


  • @blakeyrat said:

    Hey guess what: the OS I laud for getting everything right? They got that right, too!
    Shockingly enough, you and I agree on this. I've always thought the original Mac was done correctly. I loved that interface.


    Still, that's from the original Mac. When the technology was new 30 years ago. Is that tutorial still in Mac OS today?


  • Considered Harmful

    @nonpartisan said:

    @blakeyrat said:
    Hey guess what: the OS I laud for getting everything right? They got that right, too!
    Shockingly enough, you and I agree on this. I've always thought the original Mac was done correctly. I loved that interface.


    Still, that's from the original Mac. When the technology was new 30 years ago. Is that tutorial still in Mac OS today?


    Wow, that user interface looks very similar to Workbench on my Amiga 500.



  • @blakeyrat said:

    No; they suck because they have tons of issues. Raymond Chen spells them out here, so I won't rehash. (Note: some of those things Chen points out apply only to .ini files, but most of them apply to all text-based configuration files.)
    No, INI files were used for Windows 3.11 and earlier, some 20+ years ago. You jumped my shit some time back when I mentioned problems with Registry corruption. You said that was Win2K (even though I believe I said I'd had it happen under XP as well; haven't seen it under 7 or 8 yet). Nevertheless, you're bringing up problems that are Windows-specific to INI files and are 20+ years old.


    This tired argument comes up every 3 months or so. It's the epitome of troll behavior to be able to get everyone stirred up every time.


    Here's an olive branch: you don't understand how people find the Linux/UNIX paradigm of its CLI and text file configurations to be any more efficient than what you can do. Fine. I have problems with GUI configuration tools when they restrict me from doing things that I know can be done by editing text files directly. I've also had problems where the GUI config tool was unable to deal with a corrupted configuration, or a setting it didn't expect, or the tool just flat out being buggy. So my olive branch is: I'll continue using Linux and Linux-based tools and daemons. You continue using Windows and Windows-based tools to get your work done. We're not going to agree. No amount of discussion is going to convince you because you don't want to be convinced nor do you want to try to understand. For my experience, I've seen the advantages in the way I work. I came up on on Apple ][ using Applesoft BASIC and CP/M, then PC-based machines using DOS variants. So text is what I came up with. And I continue to be more efficient with text than I do with GUI.


    You do it your way, we'll do it ours, and we won't try to convince each other one way or the other because it'll never happen. If you have any questions and you would like assistance, we'll try to explain how to accomplish things. I, however, will stay away from the "why"s because you won't want to listen to them.



  • @nonpartisan said:

    Here's an olive branch

    Please take that branch and shove it up your behind. if you don't know why, read the following.

    @nonpartisan said:

    You do it your way, we'll do it ours, and we won't try to convince each other one way or the other because it'll never happen. If you have any questions and you would like assistance, we'll try to explain how to accomplish things.

    People who speak on behalf of a group without having been appointed spokeperson are annoying. People who speak on behalf of a vague group are annoying and pathetic. They think it gives them some kind of authority but really they are just wimps.

    So speak for yourself and stop pretending that The Group is behind you. We are not.



  • @flabdablet said:

    Those all run Debian, they just work, and when I mess about with them it's fun.

    HOW!? I can't think of anything LESS fun than this shit.

    @flabdablet said:

    when I'm having my time wasted by a Windows box it's because I'm trying to figure out how to suppress some irritatingly dysfunctional behaviour that's been pissing me off for weeks (like automatic updates slowing the machine to a crawl and/or forcibly restarting it right when I need it to do its fucking job and get out of my face).

    I always see this complaint about Windows, and I don't get it. Windows updates itself silently at 3:00 AM overnight. How is this happening to you? Just look for the Windows Update icon when you go to bed or leave the office or whatever, and leave the computer running that way.

    @flabdablet said:

    I'm also a big fan of software that's not trying to upsell me every five minutes

    Which is... something Windows does? Huh?

    @flabdablet said:

    and doesn't need anti-malware bandaids to stop the house teenagers rendering it inoperable by downloading fuck knows what into fuck knows where for fuck knows why.

    That's a problem of popularity, not OS design or philosophy.

    @flabdablet said:

    But if learning Bourne shell and only enough of the Linux CLI userland to let you do your job is something you're doing with gritted teeth while clinging to a principle that CLIs as a class are just Wrong From The Start, you're unlikely to enjoy it much.

    How could ANYONE enjoy this? "Whee! Guys I'm having so much fun! Some idiots made a computer that's really fucking hard to use, and I'm spending weeks figuring out the most basic tasks! I can't imagine anything so enjoyable!"

    If you think that's "fun", there is something wrong with your brain.

    @flabdablet said:

    Personally I did it because I was curious about it, and as somebody with a strong aesthetic appreciation for elegance in language design,

    What elegance? You are insane.



  • @Ronald said:

    We are not.

    People who speak on behalf of a group without having been appointed spokeperson are annoying. People who speak on behalf of a vague group are annoying and pathetic. They think it gives them some kind of authority but really they are just wimps.



  • @blakeyrat said:

    Windows updates itself silently at 3:00 AM overnight.

    @reality said:
    Windows updates itself obnoxiously whenever you are using your computer. The updates almost always break things unrelated to what the update was supposed to fix. Your computer is forced to reboot whenever the fuck microsoft feels like it, which is usually when you're playing video games.



  • @Ben L. said:

    @Ronald said:
    We are not.

    People who speak on behalf of a group without having been appointed spokeperson are annoying. People who speak on behalf of a vague group are annoying and pathetic. They think it gives them some kind of authority but really they are just wimps.

    Is this some kind of meta-sarcasm or are you just that lame



  • @gilhad said:

    INI files don't support Unicode.  - WINDOWS ONLY PROBLEM

    The INI file format does not support Unicode. It's well-documented; there is no debate about this.

    The problem you have is that a bunch of Linux-using idiots read existing .ini files, assumed they knew the file format based on what they saw, and shat out something like php.ini. But php.ini isn't an INI file; it violates the spec in a million different ways.

    @gilhad said:

    Multiple writers to an INI file can result in data loss.
    - Ususally you need not write to INI files concurently - so no real problem

    If it can happen, it's a problem. Even if it "usually doesn't". What kind of shitty software engineer are you? "We don't need to put seatbelts in this car, cars usually don't crash into shit."

    @gilhad said:

    INI files contain only strings.
    If you wanted to store binary data, you had to encode it somehow
    as a string. - Nice, so far I had encoded numbers, IP adresses and strings - so much problems with it ...

    Again, Raymond Chen is talking about the actual INI file format. There's a lot of fake-o wrong .ini files in the world, he's not talking about those.

    @gilhad said:

    Many programs open INI files and read them directly.
    This means that the INI file format is locked and cannot
    be extended.
    Even if you wanted to add security to INI files, you can't.
    What's more, many programs that parsed INI files were buggy,
    so in practice you couldn't store a string longer than about
    70 characters in an INI file or you'd cause some other program
    to crash. WINDOWS ONLY PROBLEM

    Explain how. In fact, I imagine the reams of "fake-o INI" files in use by the Linux community are even worse, since NONE of them are based on a documented file format, they're all ad-hoc.

    @gilhad said:

    INI files are limited to 32KB in size.
    WINDOWS ONLY PROBLEM

    Nope, that's in the INI file spec.

    @gilhad said:

    INI files contain only two levels of structure. WINDOWS ONLY PROBLEM

    Nope, that's in the INI file spec.

    @gilhad said:

    MAINLY WINDOWS ONLY PROBLEM- on Linux you have those files in /etc and in ~/.progname

    Don't bullshit me. It's a HUGE problem in the Linux world, and you fucking know it.

    Gilhad, I'm 100% eager to debate with you, but you gotta stop this shit. You keep saying stuff that's DEMONSTRABLY false and wrong and just passing it along as if it's gospel. Last post, it was the "a set of CLI instructions work with every single Linux distro", now it's "there's only two possible places text configuration files in Linux can live". You're a liar, and I can't debate with a liar.

    @gilhad said:

    So to sum your note: WINDOWS sucks with INI files.

    No; text-based configuration files suck. You haven't provided any evidence otherwise.



  • @flabdablet said:

    Unix was originally built for text processing, and it has a shitload of useful tools for doing that.

    Yeah but this is 2013. Nobody does that. We're all creating graphics, audio, video, surfing the web, etc.

    @flabdablet said:

    Reading system logs in Windows is slow, because Event Viewer sucks.

    No argument there.

    @flabdablet said:

    Want to do a search and replace in the Registry because you're moving the root of the user profiles tree to a different drive?

    ... why would you be doing that?

    I love this argument. "Windows makes it really difficult to break shit! That's a flaw!" Uh, no. That's a feature.



  • @Salamander said:

    No you can't. Any edit you make must be something understood by the program using the configuration file.

    And who says you can't have comments in a binary file?

    Just FYI, the Registry (that hated binary blob) is full of comments. Most of them chiding shitty programmers who dive into RegEdit to find some piece of system data instead of looking it up in the API reference.



  • @gilhad said:

    OK, give me such tools, which I could use both manually and in scripts and I will use them most of the time. Until I will come to something, that such tool is not able to do as simply as I can by editing text file.

    And then you leave off a carriage return, and nothing fucking works and you have no fucking clue why. Sorry, Salamander is 100% right on this one.

    @gilhad said:

    Are we talking about some mystery future configuration tools, which will be written by spendind many people-years in some distant future, or about what we have now and here and what is relativelly probable in next year or two?

    No; we're talking about the concept of a CLI vs. the concept of a GUI. We're not talking about some specific GUI vs. some specific CLI.

    Windows sucks in many, many ways. Nobody's saying "you must be IDENTICAL to Windows", because that's retarded. On the contrary, I'd like to see Linux be significantly better than Windows. It'll never happen, because after 15 years, Linux developers can't even make something "as good as" Windows. But it'd be nice.

    @gilhad said:

    Except that writing such tool to be usefull and convenient to use AND to be able set  ALL possible configuration combinations AND be easily accesible from scripts is still so terribly much of work, that nearly nobody does it. And so we are stuck with incomplete and inconvenient restrictive tools usually.

    So blame the guy who wrote the shitty tool.



  • @Ronald said:

    @nonpartisan said:
    Here's an olive branch

    Please take that branch and shove it up your behind. if you don't know why, read the following.

    @nonpartisan said:

    You do it your way, we'll do it ours, and we won't try to convince each other one way or the other because it'll never happen. If you have any questions and you would like assistance, we'll try to explain how to accomplish things.

    People who speak on behalf of a group without having been appointed spokeperson are annoying. People who speak on behalf of a vague group are annoying and pathetic. They think it gives them some kind of authority but really they are just wimps.

    So speak for yourself and stop pretending that The Group is behind you. We are not.

    . . . And you didn't just do the same thing . . . How?

    Go fuck yourself. Blakey does this on a regular basis. It's so fucking tiresome. He doesn't want to learn, he doesn't learn, and he just argues and whines. His way is not the only way. The UNIX way is not the only way. People actually get work done in either environment. If trying to manipulate a Linux envuronment is too much for him he should see if his boss will let him build the system in the way he knows how rather than relentlessly bitching about an environment he doesn't (and doesn't WANT to) understand.



  • @gilhad said:

    There is much larger range of tools for manipulating text and when the configuration/logs/events/whatever is text based, it can be managed by the (fast and powerfull) text manipulating tools.

    But NOBODY DOES THAT! That represents something like 0.0001% of computer usage! Why would you optimize for that use-case!? It boggles my mind.

    @gilhad said:

    GUI tools are good for easy tasks.

    Like editing an poster-sized image with 47 layers, or editing 100 video tracks in a coherent episode of a TV show, or creating a 20-track background music track for the TV show and inserting it? Creating a character in a video game, complete with motion-captured animation, collision, phsyics and 50,000 polygons? "Easy" tasks like those?

    No, those aren't easy. Those tasks are fucking hard. And all of them are done in the GUI, exclusively. Because the CLI sucks ASS for difficult tasks.

    Tell you what, YOU tell ME what hard task the CLI is good at accomplishing. I'm genuinely curious to know what type of tasks you think those are.

    @gilhad said:

    With text data and text manipulating tools you have much large range of possible actions and you can solve much harder tasks with relative easiness.

    This is like the 8th time in the last 5 posts. Nobody does that. Nobody manipulates text or deals with "text data". Data's in databases, either SQL or otherwise. Why would you optimize for a use-case NOBODY USES?

    It just shows the lack of any logic or guidance or leadership in the Linux community.



  • @joe.edwards said:

    Linux - and say Harley Davidson if we want to keep the analogy going forever - is targeted at a demographic of enthusiasts, who value freedom of choice over ease and safety. And I don't see anything wrong with that.

    That's fine, until they FORCE their shitty wrong beliefs on me. Then it becomes not-fine.

    If I have a web developer coming to me and saying they need a Linux server because it's "better than Windows", then it better fucking be better than Windows, or they are a liar and an asshole. Guess what: turns out they're a liar and an asshole.



  • @Cassidy said:

    employ someone who knows Linux commands to do the admin stuff. You direct them to what needs doing they work out the commands to do it. You need a geek that's willing to accept they may know all there is to know about firearms, but you're the one telling them what to shoot and when.

    I've brought this up like a dozen times in the last 6 months.

    @Cassidy said:

    invest time in learning Linux stuff - gain the know-how yourself. I'd advise against this completely; you already have prior baggage and it doesn't make any financial sense at all skilling you up to a level of capability that will be used occasionally. Buying in capability is a cheaper option.

    Right.

    @Cassidy said:

    replace the *nix shite with something you can manage confidently and capably. If you're responsible for it, you should have a say in what methods you'll use to deliver business functionality. This could be an expensive one-off cost, but this way you'll get to properly design and implement something you know to be sound, rather than picking up someone's discarded half-efforts.

    The developer will refuse to use the server if it's Windows and they can't use their shitty ass SSH and Github to deploy to it. (Yes, yes, I know in theory I could set that shit up, but those tools are even MORE shitty in Windows somehow.) (PHP, somehow, is actually pretty easy to set up in IIS7. But since most PHP coders are shit, they use non-cross-platform code and your PHP scripts are likely to break anyway.)

    If left to his own devices, the developer will deploy a server without redundancy, without backups, without monitoring, without regular security updates, etc.

    The best option for the company is for me to do it, since I can guarantee a responsible server setup. And I'm not enough of a dick to make an ultimatum.

    @Cassidy said:

    You're in a shit position and I don't envy it. But unless you opt for one of those alternative routes, you're just prolonging the same plod down Frustration Street.

    Yup. I'm looking for new employment, is really the "solution" here.



  • @nonpartisan said:

    @Ronald said:
    @nonpartisan said:
    Here's an olive branch

    Please take that branch and shove it up your behind. if you don't know why, read the following.

    @nonpartisan said:

    You do it your way, we'll do it ours, and we won't try to convince each other one way or the other because it'll never happen. If you have any questions and you would like assistance, we'll try to explain how to accomplish things.

    People who speak on behalf of a group without having been appointed spokeperson are annoying. People who speak on behalf of a vague group are annoying and pathetic. They think it gives them some kind of authority but really they are just wimps.

    So speak for yourself and stop pretending that The Group is behind you. We are not.

    . . . And you didn't just do the same thing . . . How?

    Go fuck yourself.

    You know what, I almost added a sarcasm indicator on that "we" but I figured that the bold tag was enough. I forgot that there is a large proportion of retards dullards morons corkies people within autism spectrum disorders in this forum.

    @nonpartisan said:

    Blakey does this on a regular basis. It's so fucking tiresome.
    And the best thing you came up with is to be tiresome yourself.



  • @blakeyrat said:

    The INI file format does not support Unicode. It's well-documented; there is no debate about this.

    The problem you have is that a bunch of Linux-using idiots read existing .ini files, assumed they knew the file format based on what they saw, and shat out something like php.ini. But php.ini isn't an INI file; it violates the spec in a million different ways.

    You can't have it both ways. Either Linux uses the INI file per spec or it doesn't. Most of the config files are not INI-format files that follow the spec. Ergo your argument is utterly useless. I don't know of any core config files that follow it (PHP is not core). I can have a 3 gig config file if I so choose and need. It can be in Unicode. File locking and techniques for making atomic changes eliminate the inconsistencies. Etc.

    You haven't shot your argument in the foot; you've completely blown a damn leg off.



  • @nonpartisan said:

    Here's an olive branch: you don't understand how people find the Linux/UNIX paradigm of its CLI and text file configurations to be any more efficient than what you can do.

    I understand enough to know that it's NOT any more efficient, and most of what I do on my computer I literally can't do AT ALL in that interface. (For example, editing my YouTube videos.)



  • @Ben L. said:

    @blakeyrat said:
    Windows updates itself silently at 3:00 AM overnight.

    @reality said:
    Windows updates itself obnoxiously whenever you are using your computer. The updates almost always break things unrelated to what the update was supposed to fix. Your computer is forced to reboot whenever the fuck microsoft feels like it, which is usually when you're playing video games.

    The only way it could POSSIBLY update during your video game is if you ignored the update icon for LITERALLY 72 HOURS. If Microsoft pushes a security update and you ignore it for THREE FULL DAYS, you deserve to get your video game interrupted.



  • @nonpartisan said:

    You can't have it both ways. Either Linux uses the INI file per spec or it doesn't. Most of the config files are not INI-format files that follow the spec. Ergo your argument is utterly useless.

    No; the argument is that text-based configuration sucks.

    The reason I was talking about INI files was because Gilwhatsisass brought it up. He is apparently ignorant that an actual INI file spec actually exists, and therefore all of his bulletpoints were fucking stupid.

    Especially the one where he said a flaw wasn't worth fixing because it "usually doesn't" come up, and the other one where he claimed Linux doesn't have the problem of dozens of buggy ad-hoc INI file parsers, which he gave zero evidence for.

    @nonpartisan said:

    It can be in Unicode. File locking and techniques for making atomic changes eliminate the inconsistencies. Etc.

    Why not have the OS enforce that, instead of trusting 47,000 developers to get it right? Derp?

    You're ignoring a lot of the points, too: for example, the impossibility of fine-grained permissions, and the impossibility of central administration.



  • @blakeyrat said:

    @nonpartisan said:
    Here's an olive branch: you don't understand how people find the Linux/UNIX paradigm of its CLI and text file configurations to be any more efficient than what you can do.

    I understand enough to know that it's NOT any more efficient, and most of what I do on my computer I literally can't do AT ALL in that interface. (For example, editing my YouTube videos.)

    And as I said, there's a place for a CLI and a place for a GUI. But this thread has NOT been about editing videos via CLI. It has been about the philosophical differences of rename vs move and installing/configuring Apache or another Web server. And about what's easier to use for configuring a system. I would never use a CLI to edit a video, nor would I have ever argued it was.



  • @Ben L. said:

    @blakeyrat said:
    Windows updates itself silently at 3:00 AM overnight.
    @reality said:
    Windows updates itself obnoxiously whenever you are using your computer. The updates almost always break things unrelated to what the update was supposed to fix. Your computer is forced to reboot whenever the fuck microsoft feels like it, which is usually when you're playing video games.
    Group policy here prohibits automatic updates. Presumably, the intent is that IT will push updates to the users, but they never do, leaving the users to do it manually (whenever they happen to think about it, if they do), which means updating when the user is here and working. Which means interrupting their work to reboot. Sometimes more than once. Which means all the context of what I'm working on -- the 6 Windows Explorer windows, 17 browser windows, command shell, 2 power point presentations, 2 Word documents and 5 spreadsheets -- all goes away.

    Actually, it's probably better to update and reboot manually. At least then there's a chance I'll remember most of what I had open, as opposed to walking in in the morning and finding everything gone, and having to figure out what is the difference, if any, between the last saved version of the documents I had open and the version Office auto-saved when it was forcibly closed by Windows.

    On the other hand, Linux only needs to be rebooted for kernel updates, which don't happen all that often. No application (including core utils) updates require reboots. And it sure doesn't need to be rebooted every so often "just because."



  • @gilhad said:

    @Salamander said:
    Besides, I disagree with the notion that text editors are configuration tools for a specific program. They are text editors. They do not know anything about the file format (Which does exist, albeit implicitly); they just happen to not fail spectacularly the moment you try using them.

    Which is more, than do nearly all GUI tools I met on Windows...

    What? The vast majority of configuration editors on windows are embedded into the GUI of the programs themselves and restrict the hell out of what you can change.
    You cannot, for example, go into Windows Explorer and set "ShowHiddenFiles=Dog". Because that would be stupid.

    @gilhad said:

    While using GUI I must make changes understood by BOTH of the program AND the GUI editor. Also I found hard to automate tasks over GUI editors, especially, if they change a little on each update.

    Changes are understood by both the program and configuration tools if they use the same config editing API. If the tool cannot handle all values coming out of the config file, then that's a bug.
    Also, why are you hung up on the idea that such tools would be limited to a GUI only?

    @gilhad said:

    Are we talking about some mystery future configuration tools, which will be written by spendind many people-years in some distant future, or about what we have now and here and what is relativelly probable in next year or two?

    Considering those things currently don't exist in Linux, yes, those things would need to be made some time in the future.
    I'm not sure where you're getting the idea that it would take more than a year. Hell I'm not sure it would take more than a month for a single person; binary formats are fairly simple at their core.

    @gilhad said:

    Except that writing such tool to be usefull and convenient to use AND to be able set ALL possible configuration combinations AND be easily accesible from scripts is still so terribly much of work, that nearly nobody does it. And so we are stuck with incomplete and inconvenient restrictive tools usually.

    That's because everyone on Linux has avoided them for so long they are too stupid to know how to do it correctly.
    As for making it accessible from scripts: Well, you have an config editor API available from the tools, yes? Is it really that hard to implement shell programs which wrap an API? (Hint: The answer is "No").

    @gilhad said:

    No, but I had many times seen, that configuration tools rejected some kinds of configuration (or just not offered), but program gladly accepted it and worked properly.

    Then the tool was shit, and using it makes about as much sense as trying to read a HTML file with an XML parser.



  • @HardwareGeek said:

    On the other hand, Linux only needs to be rebooted for kernel updates, which don't happen all that often. No application (including core utils) updates require reboots. And it sure doesn't need to be rebooted every so often "just because."

    Except that the applications you update need to be restarted for the changes to take effect.
    Given how many dependencies there are on Linux, it may just be easier to restart "Just because" than to work out what needs restarting.



  • @blakeyrat said:

    @gilhad said:
    INI files don't support Unicode.  - WINDOWS ONLY PROBLEM

    The INI file format does not support Unicode. It's well-documented; there is no debate about this.

    The problem you have is that a bunch of Linux-using idiots read existing .ini files, assumed they knew the file format based on what they saw, and shat out something like php.ini. But php.ini isn't an INI file; it violates the spec in a million different ways.

    And who cares about idiotic ways WINDOWS shoot themself to leg? If there is text based config file, then it can contain anything, the author of the file/program consider usefull, regardless of some Windows stupidity. Text config files was here before Windows, text config files will be here after windows and your stupid restrictions will be abnomination, which hit only the fuking shitty Windows.

    @blakeyrat said:

    @gilhad said:
    Multiple writers to an INI file can result in data loss. - Ususally you need not write to INI files concurently - so no real problem

    If it can happen, it's a problem. Even if it "usually doesn't". What kind of shitty software engineer are you? "We don't need to put seatbelts in this car, cars usually don't crash into shit."

    You are talking about Windows again, do not you? For last 30 years I did not hit this problem not even onece. But Windows crashed on my computer hundered times. What a shity OS it is, if it cannot live even with itself alone?

     @blakeyrat said:

    @gilhad said:
    INI files contain only strings.
    If you wanted to store binary data, you had to encode it somehow
    as a string. - Nice, so far I had encoded numbers, IP adresses and strings - so much problems with it ...

    Again, Raymond Chen is talking about the actual INI file format. There's a lot of fake-o wrong .ini files in the world, he's not talking about those.

    So we agree, that WINDOWS INI files are shit, while this problem do not affect other textfiles  configs.

     @blakeyrat said:

    @gilhad said:
    Many programs open INI files and read them directly.
    This means that the INI file format is locked and cannot
    be extended.
    Even if you wanted to add security to INI files, you can't.
    What's more, many programs that parsed INI files were buggy,
    so in practice you couldn't store a string longer than about
    70 characters in an INI file or you'd cause some other program
    to crash. WINDOWS ONLY PROBLEM

    Explain how. In fact, I imagine the reams of "fake-o INI" files in use by the Linux community are even worse, since NONE of them are based on a documented file format, they're all ad-hoc.

    Linux config textfiles are documented and they are not those shity WINDOWS INI files, who cannot contain even longer line. So again, we agree, that this problem hits only those shitty WINDOWS INI files, not textfiles configs per se.

     @blakeyrat said:

    @gilhad said:
    INI files are limited to 32KB in size.
    WINDOWS ONLY PROBLEM

    Nope, that's in the INI file spec.

    Which affects only  those shity WINDOWS INI files not textfiles configs per se.

     @blakeyrat said:

    @gilhad said:
    INI files contain only two levels of structure. WINDOWS ONLY PROBLEM

    Nope, that's in the INI file spec.

    Which affects only  those shity WINDOWS INI files not textfiles configs per se.

     

    So to sum it - WINDOWS INI FILES are totally fucked. We agree on that. Raymond Chen agree on that. Everybody agree on that. - but it does not have anything common with text config files - it is just that WINDOW INI FILES ARE FUCKED. Linux do not use fucked WINDOWS INI files. Linux use text config files, which is something you probabelly cannot take in you fucked head.

    @blakeyrat said:

    Gilhad, I'm 100% eager to debate with you,
    No, you are not. You are debating with something in your head, which is totally fucked up and screws you vision of world around you.

    @blakeyrat said:

    Last post, it was the "a set of CLI instructions work with every single Linux distro",
    Your imagination. Nearest I was saying, that modifying underlying text files is more universal, then describing pictures of every possible GUI

    @blakeyrat said:

    @gilhad said:
    So to sum your note: WINDOWS sucks with INI files.

    No; text-based configuration files suck. You haven't provided any evidence otherwise.

    So all you can say is - your evidence about text config files on Linux is flawed, becase WINDOWS INI files are totally fucked and this totally fucking affects WINDOWS INI files ONLY, as ONLY WINDOW INI files have totally fucked definition, which have no relevance to textfiles as config files on Linux. And from this you somehow decide, that all other systems and all text config files HAS THE FLAWS SPECIFIC TO WINDOWS INI FILES ONLY. 

     

    Man, you logic is sooo fucked.

     



  • WAIT

    Your argument against text-based configuration files is "if two things write to a file at the same time, bad shit goes down"?

    Hey, moron. Yes, you. The moron staring blankly at this post.

    That argument works equally well against having multiple processes on a computer, or having multiple threads in a program.

    THAT IS TO SAY

    it doesn't fucking work at all you moron.


  • @Ben L. said:

    Hey, moron. Yes, you. The moron staring blakey at this post.

    FTFY

     



  • @gilhad said:

    If there is text based config file, then it can contain anything, the author of the file/program consider usefull, regardless of some Windows stupidity.

    Protip: binary storage can contain anything as well.
    I really didn't think this needed saying, but apparently it does.



  • @Salamander said:

    @gilhad said:

    If there is text based config file, then it can contain anything, the author of the file/program consider usefull, regardless of some Windows stupidity.

    Protip: binary storage can contain anything as well.
    I really didn't think this needed saying, but apparently it does.

    Protip: all data stored on computers is text in some encoding
    I really didn't think this needed saying, but apparently it does.


  • @blakeyrat said:

    @gilhad said:
    There is much larger range of tools for manipulating text and when the configuration/logs/events/whatever is text based, it can be managed by the (fast and powerfull) text manipulating tools.

    But NOBODY DOES THAT! That represents something like 0.0001% of computer usage! Why would you optimize for that use-case!? It boggles my mind.

    I optimize for it, because I use it. That is enought for me. (Your arguments go about the line "Eat shit - those miriards of flyes cannot be wrong")

     

     

    @blakeyrat said:

    @gilhad said:
    GUI tools are good for easy tasks.

    Like editing an poster-sized image with 47 layers, or editing 100 video tracks in a coherent episode of a TV show, or creating a 20-track background music track for the TV show and inserting it? Creating a character in a video game, complete with motion-captured animation, collision, phsyics and 50,000 polygons? "Easy" tasks like those?

    By these arguments you want to show me, that I was wrong with stating, that "GUI tools are good for easy tasks."? Yo want me to appologize and say,that I was wrong and GUI is NOT good for easy tasks?

    @blakeyrat said:
    @gilhad said:
    With text data and text manipulating tools you have much large range of possible actions and you can solve much harder tasks with relative easiness.

    This is like the 8th time in the last 5 posts. Nobody does that. Nobody manipulates text or deals with "text data".

    I do. That is enought people for me to care about it. (Also lot of other people does so. But even one means, that NOBODY is not valid argument)

     



  • @blakeyrat said:

    @gilhad said:
    OK, give me such tools, which I could use both manually and in scripts and I will use them most of the time. Until I will come to something, that such tool is not able to do as simply as I can by editing text file.

    And then you leave off a carriage return, and nothing fucking works and you have no fucking clue why.

    Then I can add carrige return in text editor and everything works. Much easier than wait years for GUI update, which may or may not solve my todays needs.

     

    @blakeyrat said:

    @gilhad said:
    Are we talking about some mystery future configuration tools, which will be written by spendind many people-years in some distant future, or about what we have now and here and what is relativelly probable in next year or two?

    No; we're talking about the concept of a CLI vs. the concept of a GUI. We're not talking about some specific GUI vs. some specific CLI.

    So all your rants about how WINDOWS INI files are fucked, because the definition of WINDOWS INI files is fucked is totally irrelevant  to this debate. Also all your arguments why are text config files wrond, based on how SPECIFIC WINDOWS INI files are totatlly fucked.

    @blakeyrat said:

    Windows sucks in many, many ways.
    Agree. That is, why I do not use them and will not use them.

    @blakeyrat said:

    Nobody's saying "you must be IDENTICAL to Windows", because that's retarded.
    and then you say, that Linux text config files are bad, because do not have problems imposed by totally fucked definitions of WINDOWS INI files ... so I agree, You are retarded.

    @blakeyrat said:

    @gilhad said:
    Except that writing such tool to be usefull and convenient to use AND to be able set  ALL possible configuration combinations AND be easily accesible from scripts is still so terribly much of work, that nearly nobody does it. And so we are stuck with incomplete and inconvenient restrictive tools usually.

    So blame the guy who wrote the shitty tool.

    Why blame stranger - I simply did leave Windows and all such problems disappeared. No longer need for shitty GUI tools.

     



  • @blakeyrat said:

    @nonpartisan said:
    You can't have it both ways. Either Linux uses the INI file per spec or it doesn't. Most of the config files are not INI-format files that follow the spec. Ergo your argument is utterly useless.

    No; the argument is that text-based configuration sucks.

    The reason I was talking about INI files was because Gilhad brought it up.

    just by citing the link you posted as argument.

     



  • @Salamander said:

    Protip: binary storage can contain anything as well.

    I really didn't think this needed saying, but apparently it does.
    I will speak for myself and not the group (Ronald) when I say I see nothing inherently wrong with binary. Depending on the application binary may be able to store data more efficiently, allowing it to be processed and "be ready" so to speak faster than text. In the context of config files, however, I've not seen a text configuration be inherently problematic or slow enough to even deem "sluggish" on today's machines with respect to core configurations.


    The problem I see with binary, however, is that if a byte gets corrupted or an accidental change is made to the file (take your pick as to why), the entire file may be screwed -- or at least incredibly difficult to piece back together. Binary data can be in any format. It can be TLV or it can have pointers to other parts of the file or other data that inherently defines the structure of the file. If that becomes corrupted, unless you know the format, good luck trying to recreate it yourself. If a text file gets corrupted, the overall format is likely apparent (typically individual configuration settings on separate lines) and the point of corruption fairly readily identified. Even if the file is badly damaged, you may be able to extract out the parts that are still intact and move them to another file to rebuild the configuration.


    Someone's going to bring up the idea of backups. Yes, backups are a must. But if I can have a system back up in 10 minutes from a corrupted file vs however long it may take to wake up the on-call backup admin in the middle of the night . . .


    Being in binary doesn't inherently mean you can do these things, that you can't extract out configuration data from a corrupted file, but unless you're intimately familiar with the format there's likely no practical way to do it manually. A text format tends toward allowing this.



  • @nonpartisan said:

    if a byte gets corrupted or an accidental change is made to the file (take your pick as to why), the entire file may be screwed -- or at least incredibly difficult to piece back together. Binary data can be in any format. It can be TLV or it can have pointers to other parts of the file or other data that inherently defines the structure of the file. If that becomes corrupted, unless you know the format, good luck trying to recreate it yourself.

    Cite a reason for said corruption.
    Files do not just magically become corrupted with the exception of entire filesystem corruption, at which point a damaged config file is the least of your concerns.



  • @Ben L. said:

    Protip: all data stored on computers is text in some encoding

    I really didn't think this needed saying, but apparently it does.

    Do you have a point there, or do you just like being obtuse for the hell of it?



  • @Salamander said:

    Cite a reason for said corruption.

    Files do not just magically become corrupted with the exception of entire filesystem corruption, at which point a damaged config file is the least of your concerns.
    Bullshit. As I said, take your pick. Someone mistypes a filename in a file operation. The file gets erased by an admin and a file recovery utility finds most of the data. A system crashed or was ungracefully restarted. Intermittent hardware failure. A bit of malware has disk-level access to the disk (I don't recall the name of the malware a few years ago that rewrote random sectors on the disk; started with a "W" as I recall). The entire filesystem does not need to be corrupted and there are many possibilities for corrupting the configuration. In a properly functioning system, all of those possibilities are remote. But it IS possible to corrupt the file without corrupting the entire filesystem and making the system unusable.



  • @gilhad said:

    There is some question, but I do not understand it and I do not want to read it
     

     

    "ALL DATA ON DRIVE D: WILL BE DELETED!" doesn't seem that hard to understand.



  • @gilhad said:

    And who cares about idiotic ways WINDOWS shoot themself to leg? If there is text based config file, then it can contain anything, the author of the file/program consider usefull, regardless of some Windows stupidity. Text config files was here before Windows, text config files will be here after windows and your stupid restrictions will be abnomination, which hit only the fuking shitty Windows.

    So why in the name of FUCK is it called "php.ini"? If it's not an ini file, it shouldn't be called a fucking ini file. That would be like saying "oh, the configuration file is happy.doc and it is in XML format. Ideally the file extension- even on Linux- should give some clue as to the contents. At the very least it shouldn't be some completely separate piece of information that tells you nothing about the file contents.

    @gilhad said:

    @blakeyrat said:
    @gilhad said:
    Multiple writers to an INI file can result in data loss.
    - Ususally you need not write to INI files concurently - so no real problem

    If it can happen, it's a problem. Even if it "usually doesn't". What kind of shitty software engineer are you? "We don't need to put seatbelts in this car, cars usually don't crash into shit."

    You are talking about Windows again, do not you? For last 30 years I did not hit this problem not even onece. But Windows crashed on my computer hundered times. What a shity OS it is, if it cannot live even with itself alone?

    What does that have to do with INI Files or even Config files? when it comes to configuration file corruption the Application usually just ends up rewriting it anyway. Ever unexpectedly lose configuration information? I know I have on many platforms. You can usually combat concurrency issues with configurations by simply opening them for exclusive write access. On Windows this means opening a file with FILE_SHARE_READ but not FILE_SHARE_WRITE access, and it get's enforced by the FS API. On Linux this means using a shared lock and crossing your fingers because locks are advisory and not enforced. On windows, you get a file lock by simply opening a file specifying what access other processes trying to access the file can have. On Linux, you obtain an advisory flock that may or may not be enforced; more than one process can hold an exclusive (write) flock if that exclusive lock was duplicated across a fork. This makes things simple... apparently. Not sure what the logic for THAT being 'simple' is. Apparently it reduces race conditions, which is an interesting way of turning a local problem (that is, the problem if an application having a race condition) into some grim hack inserted into the OS itself.

    @gilhad said:

    So we agree, that WINDOWS INI files are shit, while this problem do not affect other textfiles  configs.

    why is the file in question called php.ini?

    @gilhad said:

    Linux config textfiles are documented and they are not those shity WINDOWS INI files, who cannot contain even longer line. So again, we agree, that this problem hits only those shitty WINDOWS INI files, not textfiles configs per se.

    That's weird. I've not seen any documentation. The configurations of each application seem to differ entirely. Some use one format, some use another. All of them seem to add their own special features to their formats. Some use .ini extensions for their special config format, others use .config. I even saw one use .xml for a Linux configuration file... it wasn't xml.

    @gilhad said:

    Which affects only  those shity WINDOWS INI files not textfiles configs per se.

    He's talking about ini files. Again., it's called php.ini. [b]Why the FUCK is it called php.ini if it's not a FUCKING INI FILE?[/b]. I'll tell you why! Some fucktard decades ago decided to use .ini for whatever reason. And it never got changed since, so now it's called php.ini even though it has absolutely nothing in common with any format that uses .ini for it's file extension.

     

     @gilhad said:

    Which affects only  those shity WINDOWS INI files not textfiles configs per se.

    php.ini. Again. I repeat: why is it called php.ini, and not php.config. Give me ONE good reason. There isn't one.

     

    @gilhad said:

    So to sum it - WINDOWS INI FILES are totally fucked. We agree on that. Raymond Chen agree on that. Everybody agree on that. - but it does not have anything common with text config files - it is just that WINDOW INI FILES ARE FUCKED. Linux do not use fucked WINDOWS INI files. Linux use text config files, which is something you probabelly cannot take in you fucked head.

    I'm sorry... again.... php.ini. Why? why ini? It's not an ini file. Who's fucked here, exactly?

    @gilhad said:

    So all you can say is - your evidence about text config files on Linux is flawed, becase WINDOWS INI files are totally fucked and this totally fucking affects WINDOWS INI files ONLY, as ONLY WINDOW INI files have totally fucked definition, which have no relevance to textfiles as config files on Linux. And from this you somehow decide, that all other systems and all text config files HAS THE FLAWS SPECIFIC TO WINDOWS INI FILES ONLY.

    He was talking about windows ini files in terms of the fact that the file is called php.ini. If it's not a fucking ini file, why the flying fuck is it called php.ini, is essentially what he was saying. I love how you completely ignore the fact that the file has a fucking retarded name, and proceed to ignore the fact that despite your warblings there is literally no standard Linux configuration file. Some applications use one type, some use another type. Few agree on the specific formats. Come to think of it they seldom have sections, usually they are no better than Java property files- just a bunch of key-value pairs.

     




  • @nonpartisan said:

    Bullshit. As I said, take your pick.

    You never suggested any reason in your post.

    @nonpartisan said:

    Someone mistypes a filename in a file operation. The file gets erased by an admin and a file recovery utility finds most of the data.

    That's an absolutely stupid reason and you know it. It also highlights blakey's earlier points of "why is there no rollback feature?"
    If someone overwrites a chunk of a file, your immediate reaction shouldn't be "I wonder how much of it I can salvage?", it should be "Where did I put that backup?".
    In the case of a configuration file, that could be as simple as "Look in the version control software".

    @nonpartisan said:

    A system crashed or was ungracefully restarted.

    So either:
    A) Something was writing to the configuration file at the time, I.E. generating it, in which case just regenerate it.
    or B) The whole system crashed and for some reason, the filesystem decided to corrupt itself. There is no guarantee anything on the disk is in a recoverable state; Restore the whole system from backups.

    @nonpartisan said:

    Intermittent hardware failure.

    Then there is no guarantee anything on the disk is in a recoverable state; Fix the hardware and restore the whole system from backups.

    @nonpartisan said:

    A bit of malware has disk-level access to the disk (I don't recall the name of the malware a few years ago that rewrote random sectors on the disk; started with a "W" as I recall).

    Then there is no guarantee anything on the disk is in a recoverable state; Restore the whole system from backups.

    @nonpartisan said:

    But it IS possible to corrupt the file without corrupting the entire filesystem and making the system unusable.

    Cite a reason where a file gets corrupted and the system is not in an undefined state.



  • @spamcourt said:

    @flabdablet said:
    as somebody with a strong aesthetic appreciation for elegance in language design, I'm really glad I did. Bourne shell ranks with Javascript in my pantheon of sadly underappreciated languages.
    I suppose it also includes INTERCAL, BASIC, COBOL and PHP.

    INTERCAL is a joke. I think it's a very funny one. I have it filed in the same mental drawer as C++.

    BASIC is not a bad toy language. Attempts to exend it past that use case generally result in something fairly ugly. It has nothing in particular to recommend it beyond the fact that it's moderately easy to learn.

    COBOL is a vast creaking horror. As a computer language, its main design aim was readability as if it were English. As a result, the meaning of any COBOL program is generally buried under so much superfluous verbiage as to become difficult to discern. I dislike it intensely, along with all its spiritual descendants (the most relevant of which, for this discussion, would have to be AppleScript).

    PHP is unappreciated, not underappreciated, for good and sufficient reason.

    I'm not attempting to argue, by the way, that Bourne shell is perfect. Like any useful computer language it has its warts. But it does what it was built for really effectively, and has enough depth to handle some truly bizarre use cases. It's syntactically quite concise, and well documented with similar concision: everything you need to know about it is right there in its man page, and I have yet to find a case where what it does is not what the documentation said it was going to do. It cooperates beautifully with other tools. The bash extensions got fitted into it without making it any uglier: this is in total contrast to certain other shells I won't mention, which are much younger than Bourne shell and yet are now deprecated while sh remains in widespread use.

    The reason Bourne shell hasn't been "fixed" is that, in stark contrast to many tools that followed it without managing to learn from it, it isn't broken. Flawed yes, and it's been extended in various ways to address those flaws, but broken? Absolutely not.



  • @BC_Programmer said:

    php.ini. Again. I repeat: why is it called php.ini, and not php.config. Give me ONE good reason. There isn't one.
    Because Rasmus Lerdorf made a mistake in naming it with a .ini extension and it stuck. Shall we bow to you as the programmer who has never made a mistake?



  • @nonpartisan said:

    Because Rasmus Lerdorf made a mistake in naming it with a .ini extension and it stuck. Shall we bow to you as the programmer who has never made a mistake?

    Generally when people make mistakes, they, I dunno, try and fix them.



  • @Salamander said:

    @flabdablet said:

    Reading system logs in Windows is slow... And on and on and on.

    So the tools written for all that stuff happened to be rather shitty, therefore text-based configuration is superior?
    Does not follow.

    It does follow, because all those tools needed to be written.. The thing about text editing is that it's a well-understood task and there is a shitload of tools that are extremely good at it. By using text files for system config and reporting, all that goodness becomes applicable. It also becomes possible to re-use all the existing filesystem access control stuff for config, rather than needing to re-invent all that as well.

    Your point about the ease of writing broken configurations if all you're doing is editing text has some validity. In practice, though, it gets adequately dealt with by a few overlapping mechanisms, none of which would be sufficient on their own: documentation embedded in the supplied default config files, syntax highlighting plugins for editors, and in a few cases like sudo and cron and virsh, thin wrappers for your editor that do sanity checks on what you save before letting it go live. In practice, you're more likely to do accidental damage with Regedit than with an editor (unlike editors, Regedit has no undo and all changes are instantly live) and I think this is probably why the idea of using one tool for all config looks so bizarrely unsafe and unnatural to folks who grew up with Windows.

    From a GUI user's point of view, the fact that the backing store for whatever specialized config tool they're using happens to be a text file rather than a registry key is of no consequence whatsoever. But when the GUI tools run out of steam, as they always must due to the very nature of a GUI, I'd rather have text-based config to fall back on than a remarkably poor selection of registry manipulation tools.



  • @Salamander said:

    You never suggested any reason in your post.
    I expected the reader to have an imagination.
    @Salamander said:
    @nonpartisan said:

    Someone mistypes a filename in a file operation. The file gets erased by an admin and a file recovery utility finds most of the data.

    That's an absolutely stupid reason and you know it. It also highlights blakey's earlier points of "why is there no rollback feature?"
    If someone overwrites a chunk of a file, your immediate reaction shouldn't be "I wonder how much of it I can salvage?", it should be "Where did I put that backup?".
    In the case of a configuration file, that could be as simple as "Look in the version control software".

    Or . . . it may not be that simple. It doesn't matter whether you think the reason is stupid or not. It's a reason and it's not an unheard of reason. I bow to you for never having corrupted a file. @Salamander said:
    @nonpartisan said:

    A system crashed or was ungracefully restarted.

    So either:
    A) Something was writing to the configuration file at the time, I.E. generating it, in which case just regenerate it.
    or B) The whole system crashed and for some reason, the filesystem decided to corrupt itself. There is no guarantee anything on the disk is in a recoverable state; Restore the whole system from backups.

    A) now you can't get the software up to regenerate the config because it's trying to read a corrupted configuration and you're screwed.
    B) There's no guarantee that everything is in an unrecoverable state. You may be able to verify the system can be operational while implementing a more detailed remediation plan. @Salamander said:
    @nonpartisan said:

    Intermittent hardware failure.

    Then there is no guarantee anything on the disk is in a recoverable state; Fix the hardware and restore the whole system from backups.

    There's no guarantee that everything is in an unrecoverable state. You may be able to verify the system can be operational while implementing a more detailed remediation plan. @Salamander said:
    @nonpartisan said:

    A bit of malware has disk-level access to the disk (I don't recall the name of the malware a few years ago that rewrote random sectors on the disk; started with a "W" as I recall).

    Then there is no guarantee anything on the disk is in a recoverable state; Restore the whole system from backups.

    There's no guarantee that everything is in an unrecoverable state. You may be able to verify the system can be operational while implementing a more detailed remediation plan. @Salamander said:
    @nonpartisan said:

    But it IS possible to corrupt the file without corrupting the entire filesystem and making the system unusable.

    Cite a reason where a file gets corrupted and the system is not in an undefined state.

    The file is an application configuration file that got hit during an ungraceful shutdown. CHKDSK says the filesystem is clean save for an orphan cluster that held part of the configuration file in question. Now my application isn't working.

    When I was teching in an emergency department many years back, I had a PC at one of our trauma/resuscitation rooms that corrupted for reasons unknown. Registry was corrupt, wouldn't boot, BSOD. Last Known Config wouldn't work. With text files, I may have been able to get it back up and running until I could schedule a downtime for it. As it was, I couldn't do anything and had to reimage/rebuild at an inopportune time.

    Things are not as black and white/absolute as you seem to want to think they are. Welcome to the real world.


Log in to reply