Differences between Linux and Windows Server



  • I have been studying a web site that uses ASP.NET and so it resides on a Windows Server but it also uses some JScript so it is worth studying.  Anyway, I am moving it to a Linux server and I have noticed some differences in the way it handles files.  First of all, the Windows Server is not case sensitive.  But I also noticed something else.  It seems that the Windows Server can have file names with spaces in them like this:  "Creative%20Design%20vert_S" where the "%20" is a space.  But, when I try to upload this directory to the Linux server using FileZilla it does not seem to work.  And then when I try to create the directory, I get an error "Forbidden command argument".  So is using %20 in a direcory name illegal in Linux?



  • @Xarzu said:

    I have been studying a web site that uses ASP.NET and so it resides on a Windows Server but it also uses some JScript so it is worth studying.

    What is the implication here?

    @Xarzu said:

    So is using %20 in a direcory name illegal in Linux?

    More likely it's not a restriction of Linux itself (which allows virtually anything in a filename-- even crazy things like carriage returns) but a restriction of the FTP software you're using.

    Try just typing in a space instead of a %20, and see if the FTP software does the right thing.



  • @Xarzu said:

    First of all, the Windows Server is not case sensitive.

    I think this is filesystem-specific, not Windows-generic. ISTR that there's some setting that allows NTFS to be case-sensitive; someone else will have to confirm this.

    @Xarzu said:

    It seems that the Windows Server can have file names with spaces in them like this:  "Creative%20Design%20vert_S" where the "%20" is a space.

    Actually, %20 isn't a "space" - it's a placeholder for Hex 32, which is the character code representing a space. Windows Server can have a file containing spaces that looks like: "Create Design vert_S", as can Linux. The %20 is simply something encoding that into a web-safe name, and does not make good design ethics for  web development since someone looking for a directory called "Create Design vert_S" will miss "Create%20Design%20vert_S". Having the file called "Create-Design-vert_S" may be safer.

    @Xarzu said:

    But, when I try to upload this directory to the Linux server using FileZilla it does not seem to work. 

    As Blakey mentioned, this is more an application limitation than a Linux limitation:

    @Linux said:

    $ mkdir "directory%20space"
    $ ls -d dir*
    directory%20space


    As a warning: I really wouldn't bother to try and compare difference between them in this way. Yes, they're different, for various reasons, and sooner or later you'll get fanbois and zealots dusting off their anaroks spoiling for an OS war. What probably concerns you now is how those differences affect your daily work, and if there's some platform-agnostic middle ground you can tread that safely overlaps both so the differences don't impact what you do.

    (yes, I'm a *nix nerd)



  • @Xarzu said:

    So is using %20 in a direcory name illegal in Linux?
     

    If the filename (from the filesystem/FTP perspecitve) has literal "%20"s in the filename then it will become "Creative%2520Design%2520vert_S" when accessed through the web server.

    @Xarzu said:

    But, when I try to upload this directory to the Linux server using FileZilla it does not seem to work. 

    What permissions does it have? Sometimes it might not have write or "execute" access even for the current user.

    @Xarzu said:

    And then when I try to create the directory, I get an error "Forbidden command argument"

    What FTPD is on the server? Sounds like a quoting issue somewhere.


  • ♿ (Parody)

    @Cassidy said:

    I think this is filesystem-specific, not Windows-generic. ISTR that there's some setting that allows NTFS to be case-sensitive; someone else will have to confirm this.

    In fact, the "setting" is called NTFS, which has case sensitive file names by default. Windows just can't deal with the case sensitivity of NTFS.



  • @boomzilla said:

    Windows just can't deal with the case sensitivity of NTFS.

    Nice trolling, I almost bit


  • ♿ (Parody)

    @blakeyrat said:

    @boomzilla said:
    Windows just can't deal with the case sensitivity of NTFS.

    Nice trolling, I almost bit

    Yeah, those dastardly Microsoft Trolls:
    @Microsoft Support said:

    Summary

    As part of the requirements for POSIX compliance, the Windows NT File System (NTFS) provides a case-sensitive file and directory naming convention. Even though NTFS and the POSIX subsystem each handle case-sensitivity well, 16-bit Windows-based, MS-DOS-based, OS/2-based, and Win32-based applications do not.



  • It does say that Win32-based applications can't handle it, not Windows itself (else it'd be pointless having a case-sensitive filesystem for the OS that the OS can't itself handle).



  • The troll, and of course you know this because you're Boomzilla, Master Idiot, is saying that Windows "can't" handle it, when the truth is they made a conscious decision to not handle it. Because the whole concept is fucking retarded and any OS that uses case-sensitive filenames is also fucking retarded.



  • @blakeyrat said:

    ...any OS that uses case-sensitive filenames is also fucking retarded.

    Eh? Why? I'm used to case sensitivity in pretty much everything I do (documentation, file/dir names, objects in programming, etc). The case-insensitive nature of Win threw me when I first used it.



  • @Cassidy said:

    @blakeyrat said:

    ...any OS that uses case-sensitive filenames is also fucking retarded.

    Eh? Why? I'm used to case sensitivity in pretty much everything I do (documentation, file/dir names, objects in programming, etc). The case-insensitive nature of Win threw me when I first used it.

    Probably because it's counter-intuitive for the average user, not for a programmer.  If I'm searching for SomeFileIMade.xls, I'm going to scroll down to the 's's.  If it's not there, most users aren't going to think "oh wait, let me scroll to the capital 'S's...

  • ♿ (Parody)

    @blakeyrat said:

    The troll, and of course you know this because you're Boomzilla, Master Idiot, is saying that Windows "can't" handle it, when the truth is they made a conscious decision to not handle it. Because the whole concept is fucking retarded and any OS that uses case-sensitive filenames is also fucking retarded.

    Thank you for agreeing with me about the fact that Windows can't handle case sensitivity on NTFS. I know it must have hurt you a lot to say that, which explains the tone and other stuff in your post.

    Of course, the reality is that NTFS is a little case sensitive, in that it obviously preserves the case of names. I did expect some pedantic push back with respect to applications vs the OS itself. And maybe there are super secret kernel level routines that are able to fully deal with case sensitive file names, but I kinda doubt it. What would be the point? Why create parallel functionality like that?


  • Discourse touched me in a no-no place

    @Cassidy said:

    @blakeyrat said:
    ...any OS that uses case-sensitive filenames is also fucking retarded.
    Eh? Why?
    It's not. He's just trolling. Again. Presuming of course it's not another case of his "I don't understand/like it, therefore it must be retarded." But I repeat myself.



  • Either omit the space or use "\ " (no quote marks).
    This escapes the space so it won't get parsed as an seperate argument, but rather as a single string.



  •  On the case sensitivity issue - if you think about it, it seems it would actually be easier to build a case-sensitive system, rather than a case-insensitive, since "A" and "a" aren't the same character - MS must have originally thought it would be easier for users.....



  • @HillOBeans said:

     On the case sensitivity issue - if you think about it, it seems it would actually be easier to build a case-sensitive system, rather than a case-insensitive, since "A" and "a" aren't the same character - MS must have originally thought it would be easier for users.....
    Case-insensitivity is hard, since the Unicode standard keeps adding characters, meaning that codepoints that weren't defined as differing only in case mapping in earlier version of the standard might be in a later one. NTFS "solves" this by keeping the case mapping table as part of it's on-disk structures, so a drive formatted with earlier version of Windows might treat some filenames as being different while a drive formatted with later version of Windows might treat them as being the same.



  •  @PJH said:

    @Cassidy said:
    @blakeyrat said:
    ...any OS that uses case-sensitive filenames is also fucking retarded.
    Eh? Why?
    I have to agree with Blakey on this one.  Are "Dog" and "dog" two different types of animals?  Of course not.  Why would "Dog.txt" and "dog.txt" refer to two different files?  Case sensitive filenames are like filenames containing a backspace/carriage return/other nonprinting charter -- it makes no sense and never should have been implemented in the first place.@PJH said:
    another case of his "I don't understand/like it, therefore it must be retarded
    I can't think of a reasonable explanation of why case sensitive filenames make sense.  Seriously, if you have a good explanation I would love to hear it.


  • ♿ (Parody)

    @El_Heffe said:

    I can't think of a reasonable explanation of why case sensitive filenames make sense.  Seriously, if you have a good explanation I would love to hear it.

    I imagine it's quite simple: because they are different. Is "d" the same character as "D"? Of course not. It's even worse in stuff like Turkish, though I doubt that had anything to do with the original decision. More likely it was that case sensitivity requires extra resources to deal with which simply weren't worth putting in for the convenience of case insensitivity a long long time ago, and some things don't change for the sake of not changing. Especially if it's not that big of a deal, unless you've only ever worked with case insensitive files and can't imagine using case sensitive files.

    Now, before you reply, I know that you disagree with this reason. But that's not the same as it not being a reason.



  • @boomzilla said:

    I imagine it's quite simple: because they are different. Is "d" the same character as "D"? Of course not. It's even worse in stuff like Turkish, though I doubt that had anything to do with the original decision.
    Thanks to the wonders of Unicode, you now have things like č and č, which look the same (and actually represent the same character - just that one is precomposed, and the other one is decomposed).
    č or č?


  • Discourse touched me in a no-no place

    @El_Heffe said:

    Are "Dog" and "dog" two different types of animals?
    Are 68 and 100 the same number?



  • @El_Heffe said:

    Why would "Dog.txt" and "dog.txt" refer to two different files?

    For the same reason "dog" and "Dog" are two different objects in many programming languages - the case has meaning.

    For the same reason we start a sentence (and proper noun) with a capital - the case has meaning.

    Now, I understand there are many situations where case has no meaning - an email address, URL, or spoken text (you can't hear capitals, no matter how loudly someone shouts) but we're talking about the written word, and most situations I've come across, case has meaning.



  • @Cassidy said:

    For the same reason "dog" and "Dog" are two different objects in many programming languages - the case has meaning.

     

    No. We all agree that two variables name bladibla and BladiBla is an example of really bad programming. So no, case has no meaning, regardless of whether a language treats B and b as different.

     

    @Cassidy said:

    Now, I understand there are many situations where case has no meaning - an email address, URL, or spoken text
     

    It is my conviction that file names are squarely in that list, thus should not be case-sensitive.

    To convince me otherwise will require use cases (lol pun!) where case-varying but otherwise same filenames in a single directory makes intuitive sense to a user.


  • Discourse touched me in a no-no place

    @Cassidy said:

    Now, I understand there are many situations where case has no meaning - an email address[...]
    But the local part before the @ (with one exception) is case sensitive (but most organisations treat them as case insensitive.) ISTR some broken email implementations caused problems with Yahoo Groups when the implementations decided to force the case of the auto-generated email addresses to lower case, thus breaking Yahoo's moderate-by-email and bounce detection mechanisms.



  • @Xarzu said:

    I have been studying a web site that uses ASP.NET and so it resides on a Windows Server but it also uses some JScript so it is worth studying.  Anyway, I am moving it to a Linux server and I have noticed some differences in the way it handles files.  First of all, the Windows Server is not case sensitive.  But I also noticed something else.  It seems that the Windows Server can have file names with spaces in them like this:  "Creative%20Design%20vert_S" where the "%20" is a space.  But, when I try to upload this directory to the Linux server using FileZilla it does not seem to work.  And then when I try to create the directory, I get an error "Forbidden command argument".  So is using %20 in a direcory name illegal in Linux?

    Seem like your company have tons of time to waste. What exactly is your goal you're aiming for? Working application moving to different OS is inviting disaster and complete bad karma. I wish you luck, but I have seen many titanics go down like this.



  • @Nagesh said:

    Working application moving to different OS is inviting disaster and complete bad karma. I wish you luck, but I have seen many titanics go down like this.

    I've moved many applications between different OSes, quite successfully.

    If every migration you've been involved in has been a disaster, perhaps there's a bigger issue you need to address.



  • @Cassidy said:

    @Nagesh said:

    Working application moving to different OS is inviting disaster and complete bad karma. I wish you luck, but I have seen many titanics go down like this.

    I've moved many applications between different OSes, quite successfully.

    If every migration you've been involved in has been a disaster, perhaps there's a bigger issue you need to address.

    I have been involved with just one migration, where client wanted to move from Linux based Apache to Windows based Server. It was total failure and good story for WTF. Eventually our persistence is paying off and we fix all issues. Meanwhile client business screaming at top of their voices on our poor onsite coordinator.

    Edit: I have seen several though, not direct working in that team. Our company canteen is big on these stories and we hear plenty of them each day.



  • @Nagesh said:

    I have been involved with just one migration, where client wanted to move from Linux based Apache to Windows based Server. It was total failure and good story for WTF. Eventually our persistence is paying off and we fix all issues. Meanwhile client business screaming at top of their voices on our poor onsite coordinator.

    And so the client should. It looks like his requirements were poorly-managed, resulting in loss of service.

    What you're essentially saying is that you're not good at managing change, or that your "onsite coordinator" should be conversant in project management methodology but wasn't, so got the flack for.. basically being inept.

    Whilst I agree migrations are not a simple task, you seem to be of the opinion that the risk their complexity brings means you shouldn't attempt them for fear of failure. I'm of the opinion that the change should be properly managed in a structured and controlled environment to achieve success.

     



  • @Cassidy said:

    @Nagesh said:
    I have been involved with just one migration, where client wanted to move from Linux based Apache to Windows based Server. It was total failure and good story for WTF. Eventually our persistence is paying off and we fix all issues. Meanwhile client business screaming at top of their voices on our poor onsite coordinator.

    And so the client should. It looks like his requirements were poorly-managed, resulting in loss of service.

    What you're essentially saying is that you're not good at managing change, or that your "onsite coordinator" should be conversant in project management methodology but wasn't, so got the flack for.. basically being inept.

    Whilst I agree migrations are not a simple task, you seem to be of the opinion that the risk their complexity brings means you shouldn't attempt them for fear of failure. I'm of the opinion that the change should be properly managed in a structured and controlled environment to achieve success.

     

    I am of the opinion if something is working for you, one should not find ways to stop it from working and then put blame on change management and change control figure in organization.

    I am of the opinion that unless change is ABSOLUTE and NECESARY, it should not be even thought of. Attempt is just further failure down the road.

    I am of opinion that if there is slipping bulldog in your path, you should NOT touch it.



  • @Nagesh said:

    I am of the opinion if something is working for you, one should not find ways to stop it from working

    I'm sorry - are you saying that the client's requirements were "take this thing that is currently working and FIND WAYS TO STOP IT FROM WORKING"...?

    Or did the client request that the site move between two OSes and in the move you actually stopped it from working? ie: you didn't have a plan to migrate it between the platforms and maintain service availability?

    @Nagesh said:

    and then put blame on change management and change control figure in organization.

    If the client's requirements "change it from working to non-working", then the change control figure is to be congratulated.

    If the client's requirements were "change it from working on this platform to working on THAT platform" and the person accountable for the change didn't manage it then yes, I would put the blame on that individual. Because that's what they were mandated to do, and they failed to do it.

    @Nagesh said:

    I am of the opinion that unless change is ABSOLUTE and NECESARY, it should not be even thought of.

    I am of the opinion that change must be embraced by everyone, and all changes are for the better (and improvement in situation). I am also of the opinion that to proceed with the change, there must be a business case that provides justification for the change, generally through benefits analysis.

    Saying that changes that aren't ABSOLUTE or NECESSARY shouldn't be discussed is stupid. This mindset seeks to stifle improvement and innovation until they're actually required.

    @Nagesh said:

    Attempt is just further failure down the road.

    If you do not plan changes in a structured and controlled manner, then any attempts will be met with failure. Stating that any attempt results in failure indicate, once again, that you (or your organisation) are not good at managing change.

    @Nagesh said:

    I am of opinion that if there is slipping bulldog in your path, you should NOT touch it.

    And I am of the opinion that the option to touch it, reasons why you should/shouldn't, benefits of doing so, impact of not doing so, risk of touching it are topics for discussion at a change meeting to arrive at a decision. You seem to leapfrog this step entirely and have already decided. I'm not saying that this is a bad thing, just that if this is common practise for you then it's no wonder you experience failure at changes, and your fear of that failure means you're resistant to change.



  • @Cassidy said:

    I am of the opinion that change must be embraced by everyone, and all changes are for the better (and improvement in situation).

    Too late to edit my own post, but I should clarify this bit.

    The reason why we agree to a change is for the betterment (improvement) in position, and the benefits of an improved position should outweigh the cost of implementing that improvement - this is in the business case that analyses the change so that someone can justifiably approve it.

    The reason why things needs to change is that we are driven by known and unknown forces: known because we are informed of desires and motivation to change our position (planned production increases, planned migrations, planned depreciation/outsourcing, announced changes in the marketplace) and unknown because we need to react to things outside of our control (destabilisation in the middle east, volcanic eruptions, tsunami, power cuts).

    Anyone that works in such a fast-moving environment such as the computer industry has simply got to sprint just to keep up. If you stop running and resist change, it won't stop the changes from happening around you - it just means the changes will occur despite your involvement, and the world will move on - leaving you standing behind.

    This is what I mean by "change must be embraced by everyone". We don't have to like it or agree to it, but we must accept that it occurs for reasons that dwarf us, and we must be ready to react in a productive way when the changes occur. Stubbornly stating that it must be left alone or never changed (or not until some situation forces the change) is an immature attitude to the world around you.. and also representative of many in the IT field, sadly.



  • It is very nice and informative information you share here that veru useful for the people to getting knowledge and knowing the difference between linux and windows server. This is really very useful for kowing that some of applications are not supported to linux server.


Log in to reply