Slashdot Mirror
Linux/Mac/Windows File Name Friction
lessthan0 writes "In 1995, Microsoft added long file name support to Windows, allowing more descriptive names than the limited 8.3 DOS format. Mac users scoffed, having had long file names for a decade and because Windows still stored a DOS file name in the background. Linux was born with long file name support four years before it showed up in Windows. Today, long file names are well supported by all three operating systems though key differences remain. "
Long filenames aren't all they are cracked up to be. I got made fun of once for using one. I can remember it so clearly now, we were in music theory class in high school and we had to use Finale on a Mac (OS 7 at the time) for our composition projects. I named one of my projects something like "Suso's Music Theory assignment number 4 for Mr. Becker 1993-9-24.mus" and saved it. A week later I was on the same Mac and noticed a file that wasn't mine called "Making fun of people who use really long filenames for their music theory assignments.mus". Nobody was admit to doing it but I knew who it was. I was devastated and never felt comfortable again in that class.
Now I'm scarred for life. I should have listened to my parents and gone with 8.3.
Slow news day?
Insert witty sig here.
Although it was cast as a negative, I always enjoyed being able to use the ~1 (and ~2, ~3, etc) for long names in MSDOS. In my mind Program Files is progra~1 and Microsoft is micros~1.
What a useless story...
The one part that looked slightly interesting was the tips for removing Linux files whose filenames contains symbols you can't decipher, but the article inexplicably said it would tell us how and then continued to waste more of my life.
Similarly off-topic: XMMS for Linux of WinAmp for Windows
But in this particular case, the summary has as much meat as the story, with the added benefit of saying it in a paragraph instead of several ( and even that's too long ).
For those of you who haven't read it, here it is: Windows, Linux and Mac OS X all support long file names, albeit differently. Linux is case sensitive, the others are not.
Tada! Two sentances. I imagine, were I a perl coder, I could have done it in half of one, but there you go.
Mod me down with all of your hatred and your journey towards the dark side will be complete!
Beagle is one of the coolest tools available for Linux desktops and it requires xattrs on indexed filesystems, so yes, my /home and / have xattrs enabled.
Why are computer file names and conventions and protocols so messed up? It's bizarre -- and Microsoft has been one of the worst offenders with one of the most powerful positions and opportunities to make it a better filename-naming world.
I had worked in the DOS world long ago, and I'd always been frustrated with not only the restriction of the 8.3 naming convention, but the added imposition of:
Many years later, I had opportunity to consult in the Windows/DOS world after having worked in the Unix world for over a decade -- figured Microsoft had had enough time and money to work out the kinks in what had obviously been an early-technology constraint for the brain dead old DOS naming restrictions. Not. Sigh.
And then the transition was a nightmare, whoever conjured up the VFAT naming format and the "tilde" mapping backwards compatibility to FAT names should have been shot. A golden opportunity lost.
And then everything swings completely the other direction where anything goes. This may curry favor with users, but wreaks havoc on billions of lines of code which all of a sudden choke on what had been simple parsing routines -- fixable, but at great expense. I still think this was a paradigm shift that somehow could have accommodated the user space/community but still allowed some sanity in the machine world.
But layered on, or dovetailed into that quagmire is the Microsoft insistence they "know better than thou"... and the condescending insistence of dragging the ".3" extension nightmare into the new rules for file naming. Would have been okay to "allow" ".3" naming, but to impose the bizarre rules and behaviors Microsoft has? (How many of you have files named picture.jpg.jpg.jpg out there?)
Options to show extension, defaults to hide extensions, and continued reliance and semantics applied to extensions continue to make the filenaming world a landmine field.
And, Microsoft dares to allow mixed case naming, but does case insensitive handling of file names... don't even get me started about some of the bizarre results and buggy behavior I've traced to that. I only wish I'd had a chargeback code for all of the time I've spent fixing and debugging systems that all come back to the file naming. Sigh, again.
All of this isn't to let Unix and Unix style file naming skate. I've had problems, though fewer, there. But, at least it's seemingly (to me) more consistent and predictable, though there has been what I call "Windows" creep in that there have appeared some apps that somehow think managing and imposing "transparently" the extension to "file type" mapping is a good thing (it's not).
(One of the funniest Unix debacles I experienced was debugging a groups application -- they were moving files around and losing all but one each processing cycle... turned out they were remote copying from one Unix that had 14 (or more, can't remember) char limit on file names to an old SunOS system that allowed only 11. The remote copy that moved files from one system to the other for subsequent processing did so without complaint, the receiving side silently truncated the incoming files -- which were identical in name through 11 chars... essentially copying the incoming files over and over again on top of the same file... Sigh and sheesh!)
Too bad the article didn't mention what happens when you copy long filenames over the network. All kinds of crazy things happen in all kinds of client/server combinations.
Try copying a 40 character file from a windows server to a OSX client. What happens? Well... it depends if you used appletalk or SMB to connect with.
What about OSX server -> a windows client... depends on the version of windows AND OSX of course.
I've had nightmares.
Wanna be safe most of the time:
1) No spaces
2) Under 32 character filenames
3) Alphanumeric, underscore, period, or hyphen ONLY
4) Only a single period allowed.
TMI Hemos!
I'm sure "SlashdotMedia" will improve on all the wonders that Dice Holdings blessed us all with
Oh and Mac users didn't really have support for long file names until OS X. HFS has always supported 255-character file names, but in OS 9 and earlier, the Finder would only recognize up to 31 characters for a file name, so it was basically impossible to have a file name greater than 31 characters even though the file system allowed it.
I think the biggest problem I had one day was when I was trying to remove a file in Linux who's first character was -
rm and mv kept complaining that the character after the switch wasn't valid and eventually I had to navigate to the file in X and delete its icon which did the trick.
Not a particularly exciting story, but an interesting one none the less.
Summation 2
I've got a CD-ROM that is unreadable under Windows XP because a Mac user put the files in a directory containing a '>' character.
If I can turn off Joliet comprehension I'll have access to the files in their original ISO9660 8.3 glory.
It's unfortunate that Microsoft's Joliet driver doesn't realize it's presenting names the OS can't tolerate. Otherwise it could replace the forbidden characters with % escapes before returning them to the OS. Or, alternately, handing the ISO9660 name to the OS if the Joliet name was forbidden by Windows' rules.
Is this anything other than an attempt to dis Windows for no other reason than 'Because'?
Nope.
HTH.
Richard
xxx
Summation 2
There would be about 40 "Why the hell was this greenlit".
That aside, isn't Slashdot "News for Nerds" ????
How about posting more info about why WinFS was scrapped, rather than how windows/linux/mac has been for the past X years.
Bring on the modding, my karma can take it.
So, your OS supports long filenames, huh? Then why doesn't the vendor use them for all the cryptically named shared libraries, scripts, etc. that clutter up any modern os system directory?
They way I look at it, the day I look at something like "d3d8.dll" or whatever drek is fermenting in \WINDOWS32\ and it is actually named with a descriptive filename, then that OS will truly support long filenames.
Not sure where the Linux crown compares, but OS X is getting better with each revision. Classic Mac OS had this one down (mostly) cold.
The white zone is for loading and unloading only. If you need to load or unload go to the white zone. It's a way of life
Why not simply follow the POSIX standard*? You can avoid a lot of hassles that way. Isn't that why we have standards?? I know, it doesn't resolve the conflict with Windows case "insensitivity", but ... it does provide interoperability between POSIX-compliant OSes.
* upper/lower case alphabetic characters, numeric digits, underscore, dash, and period.
From the wikipedia entry on NTFS:
"Though the file system supports paths up to ca. 32,000 Unicode characters with each path component (directory or filename) up to 255 characters long, certain names are unusable, since NTFS stores its metadata in regular (albeit hidden and for the most part inaccessible) files; accordingly, user files cannot use these names."
The article incorrectly states "Windows file names can be up to 255 characters, but that includes the full path. A lot characters are wasted if the default storage location is used: "C:\Documents and Settings\USER\My Documents\"." I will grant that this may have been a limitation in the past, but XP has had NTFS from the start, and NTFS is by far the most common windows FS today.
You can use Media Portal if you're on XP, or Knoppmyth if you want a completely different OS.
Have you looked at http://www.chipx86.com/wiki/Leaftag
El Tonerino
Using autocomplete is even faster, and (I find it) more convenient.
From Run you just select the folder/file name from the list after typing a few letters, from cmd.exe you just hit tab after typing a few letters.
Amiga has had long filename support since it was first released in 1985.
Dan East
Better known as 318230.
news - plural noun - information about recent events or happenings.
Haiku for you!
Using only 8.3 filena~1 restri~1 is not that big a deal. Even if we had to write ordina~1 english that way_ it would still be compre~1.
In honor of DOS_ or maybe CP_M_ we should have an 8.3 day. All posts must be MS-DOS 8.3 filena~1 compli~1. Maybe someon~1 could write a filter for slashc~1_
It shows that you do a rm with a wildcard. If you are having issues, be sure to run it with ls first, and then change it to rm only after checking that it is what you want.
Also what was not mentioned in the article was the difference of a pathname vs. a filename. Yes, Windows does 255 as a filename. But the more limiting item is the max_path is 255, while in typical unix it is 1024. Basically, *nix is much longer and able to go much deeper in the path.
I prefer the "u" in honour as it seems to be missing these days.
C:ONGRTLNS.W95
If Jesus wants me it knows where to find me.
Right, and c:\winnt\system32\comctl32.ocx makes it crystal clear what it's for, right?
Things like 'man' (for manual) were inherited from the days of glacially slow terminals, when you could actually type faster than things would appear on screen.
It's not that bad these days either, saves a lot of typing, especially nice when using slow SSH sessions.
File names aside, is there a good way to "tag" files (generic metadata) on Windows or Linux?
On NTFS, you can use ADS (Alternate Data Streams) to store metadata about a file, though I don't know of any software that can read such data in a consistant manner - Not to mention, just about every malware scanner out there will flag such files as suspicious.
On Linux, it very much depends on the FS you choose, though again, support for file metadata remains about as standardized as snowflakes.
I was doing tech support for Win95 way back when it came out, I think it was in 1995 (duh), I had a customer who wanted larger fonts on the desktop. I explained how to change the size of the fonts for desktop icons. As soon as we did, "Network Neighborhood" turned into "Network Neighborho...". Of course, the guys on the phone got a kick out of that and it was knows as "Net Ho" for at least a week after that.
Just thought I'd share.
There is no "I disagree" mod for a reason. Flamebait, Troll, and Overrated are not substitutes.
They have a whole block on "Avoid using these characaters for maximum portability".
But, where's the exclamation mark? TONS of Windows people (including me) use exclamation points as the first character to put files/directories to the top of the list. Linux constantly chokes on these characters. But, no mention of it at all in this article.
Well, if MS hadn't decided to use \ as a directory separator, you could just backslash it. But no. MS had to be retarded.
Goten Xiao
That's not entirely incorrect; on windows, badly behaved programs go in "Program Files" because the system directory is called "Programme" here. Some installers ignore the system settings, causing great confusion^Wfun. And some installers simply assume C: is my primary harddisk when it's really F:.
No, they go in "C:\Program Files" and the Registry and one or more users' "C:\Documents and Settings\%USERNAME%\Application Data" folder.
No, they go in "/Applications" and "/Library" and one or more users' "~/Library". Also, by the way, OS X does have /bin and /usr/bin and all the other UNIX standard folders; they're just hidden from the finder.
No, on Linux they go in "/usr/local/bin" and "/usr/local/etc" and one or more users' "~" only, because "/bin" and "/usr/bin" are reserved for bits of the OS itself (equivalent to "C:\Windows" and "/System").
"[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz
The best thing about *NIX file names is that it allows you to use really useful names like *. I was present once as a colleague execute rm * to get rid of this pesky file he'd created by accident. Oh boy was he not happy with the result.
It's just as well he didn't have a file called -rf and try to get rid of them both in the same command!
cmd.exe's completion is a bit strange if you're used to bash, but once you get to know it, you can get around quite well.
Example:
Before Windows XP, you had to activate the tab character by changing a registry key. XP has this set by default.
WWTTD?
There are several file names that are reserved in DOS\Windows
nul
prn
com1 (etc...)
Note that you can't use the above with or without an extension, i.e. nul.txt won't work.
Windows here suck the most. NTFS is good, but all the backward compatibility cruft just drags the FS down.
Once under Windows, I have spent about half an hour with Explorer refusing to copy one one. Explorer was insisting that "File No Found". Text file was there and perfectly editable by notepad. I needed about 30 minutes to observe that Explorer was giving error on only on file of whole directory and that file have had the longest name. ZOMG!!! They still have cap 255 bytes on path(!) length!!!
Welcome to 3rd millenum, Microsoft! Where do you want to go today?!?
End-Of-Sarcasm.
Realistically, I never had a single problem with Mac or Linux when handling file names. But when you get to Windows, you start getting the annoying messages from explorer "invalid character" with attached long list of characters they do not allow to use. All the time. And I'm not talking about bunch of non-Unicode applications (for example Adobe Acrobat Reader) which cannot open file with name containing international characters. Could it be any dumber?
All hope abandon ye who enter here.
Tada! Two sentances. I imagine, were I a perl coder, I could have done it in half of one, but there you go.
/. story is that people would have to stare at the resulting half a sentence for a lengthy period of time before they managed to figure out what the hell you are trying to say.
True enough but the drawback of using Perl style syntactic obfuscation to compact this
Only to idiots, are orders laws.
-- Henning von Tresckow
Not fully correct.
This way you avoid breaking the package manager, which has exclusive domain in
If I had to hazard a guess, I would say that it is common controls library for a 32-bit system or maybe computer control library (less likely) for 32-bit windows.
Sure, that's a pretty well known library. Try a few more: cewmdm.dll, bopomofo.uce, 8532.ax
/lib has just libraries, system32 is full of the weirdest stuff.
At least
Hopefully there are some developers out there that will actually USE long filenames or at least names that are clear on what the file or program does.
Don't fight for your country, if your country does not fight for you.
I seem to remember that you can use even longer paths in windows if you begin them with \?\ or something similar.
Amiga has had long filename support since it was first released in 1985.
The Amiga OFS had support for 30-character filenames in 1985.
The Macintosh MFS and Finder had support for 31-character filenames in 1984.*
A year late and a character short.
(* MFS actually supported 255-char filenames, but Finder 1.0 only allowed 63, and later 31 (!) characters.)
The US free market: two halves of a government-granted duopoly are free to set the market price.
I just hit the file name issue trying to sync some stuff between unix / Windows XP using rsync.
The case insensitivity was annoying and the limited char set on XP was no good.
Again, you would think they would have fixed this on XP.
Yes, that's what I said: pieces of the OS (which includes everything installed by the package manager) go in either /bin or /usr/bin; programs that are not part of the OS (which includes everything installed manually) go in /usr/local/bin.
"[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz
Don't forget Netware 3.12 where Win 9x clients only get long file name support if you loaded the OS/2 namespace module. Can't forget that.
My Hello World is 512 bytes. But it's also a valid Fat12 boot sector, Fat12 file reader, and Pmode routine.
I've got an Amiga CD with a file named 'CON'. Windows doesn't like that either.
...yet MS continues to name programs idiotic and needlessly cryptic things like iexplore.exe, charmap.exe, etc., etc. It's really sad that 11 years later, Microsoft still isn't confident enough to name its Windows XP+ only applications using more than 8.3 characters.
I want documents not files. Sometimes multiple files make up one document (webpage + stylesheet + media), sometimes there are multiple documents in one file (zip).
When will anyone come up with a persistant storage system which allows me to make random tags to documents and groups of documents. Drop the folders and give me 'search queries' on content and tags. Automatically save all data and don't bother me with giving it a name... When it's important I will give it the proper tags until then just remember it for me.
Do I have to name the paper before printing?
What I cannot create, I do not understand
Why did Microsoft do that? Just to be different? It is harder to type.
Stupidity is like nuclear power, it can be used for good or evil. And you don't want to get any on you.
I usually turn off short file name generation, it just seems like a wasteful thing to do in 2006.
w indows/xp/all/proddocs/en-us/fsutil_behavior.mspx? mfr=true
See http://support.microsoft.com/?kbid=121007
and other cool options at http://www.microsoft.com/resources/documentation/
No, they go in "/Applications" and "/Library" and one or more users' "~/Library".
Technically, no. The files that go in the Library directories are not programs, but configuration files (data), so tossing an old program and dropping in a new one can easily maintain the same configuration. (With the possible exception of Widgets and Services which may or may not be classified as "programs" but are really better classified as data used to provide application like features via the dashboard and OS).
I remember having a fight on a CentOS 4 box because the directories I was trying to copy from one drive to another were too long, and causing the command input buffer to not receive the entire command. What good are super long file names / directories if you have to recompile a kernel in order to sucsessfully copy a directory from one drive to another thats buried a few directories under root?
Windows has more viruses because linux has more virus coders.
Sure, that's a pretty well known library. Try a few more: cewmdm.dll,
Oh, come on. That one tells you exactly what it is if you just right click on it and select "Properties". It's the Windows CE Windows Media Device Manager Service Provider.
bopomofo.uce,
Something to do with the Zhuyin phonetic alphabet used to teach Chinese character pronunciations in Taiwan. The UC in the extension will stand for UniCode. Don't know what the E is.
8532.ax
Some kind of ActiveX filter, I think. They're just DLL files with a different extension; right-click, "Properties", read description, and you know what it is.
More to the point, though, why do you care what this stuff is? Are you seriously going to tell me you do stuff like go through all 3,000-odd system files checking to make sure you know exactly what each is for, and deleting the ones you know you don't want, or something? I mean, go right ahead if it makes you happy, but I have better things to do with my time than worry about what spcmdcon.sys might be. (But it only took me 2 seconds to ascertain that it's the "Windows NT Setup mini command console". Seriously, this ain't rocket science.)
Dos 1.0 had no directories, and arbitrarily used / for options (remember DIR /P ?). When 2.0 came out, to preserve backwards compatibility they kept / for options, so decided on \ as the directory separator. Modern dos/windows can handle / for directories fine, but they need to still support \ for - you guessed it - backwards compatibility.
I am trolling
In Windows, its valid to have myfilename.bar and MyFileName.bar in the same folder. However, one will only be shown in its 8.3 format. Which one? What happens if you delete the other one? Why can you have both, when they don't get treated equally?
By default in OS X, MyFileName.bar and myfilename.bar reference the same file (in the Finder or at the command line). In Linux and other case sensitive unix-like operating systems, MyFileName.bar and myfilename.bar are different files (OS X can handle that as well).
Windows is the only mainstream OS with a confusing, inconsistent use of case (in)sensitivity.
Is this anything other than an attempt to dis Windows for no other reason than 'Because'?
I think it is a valid issue. There are some files in a CVS module I simply cannot use on Windows because the filesystem chokes when CVS tries to write them in Windows and the rest of the CVS commit is aborted. It is a huge pain in the ass, even though these files do not contain any capital letters. This happens with ever CVS client on Windows, even Cygwin. MS needs to get off their butts and fix this crap once and for all.
I think they did it because someone had already used / as the option prefix (like in dir /w--the Linux equivalent is -, as in ls -l). So they had to use a different character.
ttuttle is a rankmaniac
> If I can turn off Joliet comprehension I'll have access to the files in their original ISO9660 8.3 glory.
Use IsoBuster. (The program is shareware, but has a free mode with less functions. The free mode is enough to access the 8.3 files)
First of all, Windows NT/2000/XP/Vista != MS-DOS/Windows 9x
NT has had long filename support since its inception and it's never been a hack, which seems to be a pretty damned good track record to me. It's silly that misinformed Microsoft bashers still crack on modern Windows for so many things that don't affect it, but rather were a trait of previous incarnations before NT (Although there's plenty to crack on NT about, as well).
The only reason I would avoid them is the god damned CVS uses "CVS" to store information that nobody wants to touch and thus screwes up all other upper-cased normal filenames under the same dir.
When will they fix it?
hmmm... dumb...
In Terminal.app, you can create file names with colon, but such character is mapped to a forward slash when seen in Finder. On the other hand, you can use forward slash in Finder, and it is mapped to a colon in the command line.
Historically, Mac OSes use colon to separate folder names in a path.
There is a subtle restriction in HFS+. All files in HFS+ have their names in normalized unicode, and in order to normalize in the first place, file names must be in valid UTF-8 encoding. You cannot use random character string for file names.
There is no such restriction for UFS on Mac OS X. I think UFS supports roughly the same characters as in BSD and Linux and any other Unices. If you're transferring files from Linux with names in a legacy encoding, you can create a UFS disk image and convert file names to UTF-8 before copying them to HFS+.
I once had a signature.
OS X supports colon on the command line. In Finder the colon will look as a forward slash. Why? Because OS X wants to support filenames with a slash eg. "sofa/car.jpg" (I believe this is a remnant from pre-OS X). Due it's *NIX heritage it cannot do that, so they chose to do this trick of showing colon as slash with Finder. Quite nice IMHO.
Summary:
I demand the Cone of Silence!
Symlinks are the best idea in fileing system. Windows still doesnt support them at all. But then i guess its too complex for most brain dead people.
../tmp
But limits ? windows is 255 what would happen to most of its apps if you did this ?
mkdir tmp
cd tmp
ln -s
I have seen windows choke on loops like these in a file system across samaba.
Yuo really knwo something is wrong when a find takes a really really long time to finish on a windows workstation!!!
What a strange question, of course I want to be able to guess what's each file for. It's my computer, and I like my computer being under my control and know what is there and why. To even suggest that I should accept that I don't know what's on my disk is ridiculous.
And what's the "Zhuyin phonetic alphabet" doing there anyway? No wonder Windows wastes so much disk space. On my server I have absolutely what's needed and nothing else, why would I want to waste space on stuff like chinese support I won't ever use anyway?
There's a whole new dimension of fun when your file names include non-Roman characters, such as Japanese.
First of all, there is the matter of which encoding the file names are in. Lots of Japanese Windows installs and their utilities still use Shift-JIS for file names. OS X, on the other hand, uses Unicode, and typically expects UTF-8 for file names from programs. In fact, it not only expects it, it enforces it, returning an error when attempting to use a file name which is invalid UTF-8.
Many command utilities that deal with archive files utterly fail on OS X when given archives using Shift-JIS file names, and many others improperly translate it as 8-bit ISO Latin I. A few (such as the command line RAR archiver) are actually smart enough to make a system call to translate the file name from Shift-JIS to UTF-8.
And then there is the issue of Shift-JIS MP3 tags. If you open those with iTunes, not only do they get interpreted as ISO Latin I, but irreversably so if you do something that writes them back to the .mp3 file. (They get written back as a UTF-8 representation of the ISO Latin.) I've had luck in the past using a hex editor and SimpleText in Classic to convert them with much work, but I'm not sure what I'll do with the new Intel Macs that don't support Classic.
--
"Open source is good." - Steve Jobs
"Open source is evil." - Microsoft
GBPVR is the only alternative you need to consider. All the others are either rubbish or to difficult to setup(don't even both looking at Myth TV, isn't that Linux only anyway?)
Also get an MVP, gbpvr has great support for this, and it allows you to watch tv/videos and other stuff on a tv.
Mac OS X's flavour of HFS is case preserving, but not case sensitive by default. However, it can be changed to be both case preserving and case sensitive if you prefer it.
I know this might sound a bit offtopic, but since the post mentioned windows filesystems, I felt it might be a good place to throw this question...
Not many people know or have even used this, but NTFS has support for multiple streams of data in a single file, which is something that borrows concepts from object-oriented filesystems. This is scarcely, if at all, included in the regular windows documentation (it is documented in the MS knowledge base http://support.microsoft.com/kb/105763/). I thought it to be a nice idea for, say, media files, to store the audio in one stream the the video in another, or adding subtitles or metainformation in different streams in a very standard way. But for some reason nobody used that, not even Microsoft who designed the feature.
Does anybody have a clue as to why this has not been used?
www.meneguzzi.eu/felipe
The actual limits were that the extension could not have more than 3 characters, and (more annoyingly) the extension always had to be there. The actual FAT storage had 11 bytes to stash the filename in, and it always stuck a period after the 8th character. The sections could be shorter by filling the unused bytes with null (? or maybe space?).
The filenames "foo" and "foo." were the same file. Programs were somewhat inconsistent as to whether they printed the period or not in this case.
You could actually make files named ".foo" which was convienent for Unix emulation, but only 3 letters. Also some programs crashed on that.
If anyone knows a way to disable this behavior, please do let me know.
- First they ignore you, then they laugh at you, then ???, then profit.
CPM, and Digitals OS family (RSX-11, RSTS) before that, used / as the option prefix (aka switch character).
// was not accepted.
By the time MS DOS 4 came out Microsoft realized that diverging from Unix was a bad idea. CMD.EXE, recognized the environment setting SWITCHAR=- as an indication that the switch character was - and that / could separate file path components. But IBM DOS 4 did nof follow suit. Furthermore, command line processing was not centralized. Every program which parsed command lines or file names - not just CMD.EXE - had to be modified if the SWITCHAR convention were to be useful.
In Windows (as opposed to CMD.EXE), the file parsing functions permit either \ or / to separate path components. And that is documented. As an exception, last time I looked, UNC names had to start with \\;
1. Run regedit.
c es\Eventlog\Application\
2. Go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Servi
3. Click on every folder underneath that one. Look at the eventmessagefile key.
Have you noticed that all of them have an 8.3 format?
It's a bug I came across in Windows. I tried to register a file for use in the Windows Event Log. It didn't have an 8.3 format. Windows barfed all over it.
Y
I was comparing the entirety of a program installation across the platforms. If you notice, I also mentioned the Windows registry, Linux home directory (for dot files) etc. as well, and those don't techically hold the programs themselves either.
"[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz
You could try opening a command prompt and escaping it with ^, but I wouldn't bet on it working.
("copy ^< con" seems to grab an arbitrary file...)
http://www.glscube.org/
HTH.
Deleted
But who uses a shell without tab completion anyway? mo done, and no silly numbers to remember/look for either.
I rememeber Apple's full page ad in the New York Times when Win95 was released:
:-)
C:\ONGRTLNS.W95
Those were the days.
I'm heading over now to re-read the gripping story of the Google plane!
"Win treats sysadmins better than users. Mac treats users better than sysadmins. Linux treats everyone like sysadmins."
I usually mount my Linux server's samba share on my iBook. Whenever I download posts from newsgroups that preserve folder structure based on post title (which often includes symbols such as '[', '~', and '*") on my iBook and want to transfer them to the server, it bitches And won't let me copy them. Yes, it's a protocol error, but I dislike that I well know Linux and HFS+ can both read these, but it won't copy....
In undeveloped countries, the consumer controls the market. In capitalist America, the market controls you.
The purpose of the "OS" (its actually not the OS here, but lets use that term to make the following discussion clear) is to provide the set of tools needed to implement your "paradigm" (again, not true, but it will do).
Your way of thinking.
As it turns out, having multiple "files" composing a "document" is easily mapped in a hierarchical layout. As a simple idea, put all the files into a node and call that node the name of the document.
The "OS" should not impose upon the applications, but should provide ready services that map well into what the application(s) want.
Unix further provides "hard" and "soft" links to allow you to do (for example) sharing. As an example; you have a boilerplate logo image. It can be hard linked into your documents.
"Random" (I do not think you really want random) can be accomplished with soft links.
Content searching? Either "find" or "grep" will do (ok, for up to several hundred megabyte of content -- and if you have hit THAT limit, let me know -- its a separate discussion).
You will have noticed that I have (so far) eschewed GUI tools in this discussion. The blatent omission of find/grep and other tools has mystified me. Either it is hard to do (semantic mapping of symbolic language to pictures) -- which is true, or the GUI designers are deliberatly dumbing things down.
It would be nice to have an "assembler" in file open boxes: I would like to be able to say "Please open a file containing project in the name, whose contents include September 10, which was last modified in 2002, of type ASCII text".
Now, all the tools to do this are included in the "CLI" interface: find, grep, ls, file. But, when we hit the GUI, these tools vanish. "NO SYMBOLIC REASONING FOR YOU - STICK TO THE CONCRETE" is the slogan.
Since the "classic" Unix GUI is basically X supporting XTERM, which in turn launches applications, the CLI is still there. But in modern Linux, Unix, OS X environments, most users are never exposed. And, in turn call for more "paradigms" to be created.
And, this is HARD. Witness Microsofts failure with "WinFS". Witness that the largest jump has been to Plan9, which extends the Unix way (by putting more stuff under this control). Witness the success of mapping things like "/proc". There really HASN'T been a new "paradigm" that offers more.
The problem is that trying to utilize the filesystem is lost in the GUI translation. Apple indexes files, by content, for GUI consumption. This is NOT a new breakthrough -- Unix has had "locate" which is most of the way there for ages. Indexing by content? Again, not new. Merging these ideas is fair, and I wish that Apple had based the kit on CLI for maximum portability.
Ratboy
Just another "Cubible(sic) Joe" 2 17 3061
it doesn't resolve the conflict with Windows case "insensitivity", but ...
I use Linux, you case insensitive clod!
Worse still, in Linux, the command to change to a new directory is called something needlessly cryptic ('cd'!?!) instead of the more useful 'change directory'. And Linux has been supporting filenames longer than 2 characters for HOW long??
Hint: Suppose the name of 'cd' or 'iexplore.exe' really did change. What would happen to your company's scripts, that were written in 1993 by a student who later died in a freak gardening accident?
Only on Slashdot would the above need pointing out, I swear!
Whence? Hence. Whither? Thither.
I was comparing the entirety of a program installation across the platforms.
Yes, but most OS X applications do not create any files in the Library directories upon installation, instead they do so the first time the program is used and saves setting/preferences information.
I'VE BEEN USING LONG FILE NAMES SINCE 1978.
I SAY THE NEXT CHALLENGE IS LOWER CASE.
HIV Crosses Species Barrier... into Muppets
Ones that are "installed" by dragging the .app folder, sure, but what about ones that use an installer script (.pkg, .mpkg)?
"[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz
One of first culture shocks for people moving from Windows to Linux is the case sensitivity of file names.
I wrote a patch that creates an "ext3ci", a case-insensitive ext3 filesystem for Linux. Because it creates a seperate driver, you can have parts of the directory tree set up as classic case-sensitive and parts insensitive. Bash's wildcard expansion still expects case sensitive names but its great for web servers and similar machines where the users are expecting case-insensitive behavior.
http://bill.herrin.us/freebies/
Moderating "-1, Disagree" is simple censorship. Have the guts to post your opinion.
I forget the specifics, but the Minix Filesystem that Linux originally used only supported fairly short filenames. IIRC, they were longer than 8.3, but still fairly short. Besides, 8.3 isn't that bad, one OS I still use (RT-11) only does 6.3.
Z.
Of course, you'd have been berated for not knowing the -- beforehand, but hey - you'd have the answer, right?
(hey, I didn't know it either, but I'm a windows weenie, so I don't count)
Is it just my observation, or are there way too many stupid people in the world?
Personally I like the Linux (Unix) method. Nothing wasted. But, have we reached the point yet were we can abstract the filesystem away from users? It's nice for an admin to be able to poke around and fix problems, but can we come up with one set of rules on filenames (Linux please!) and then have the OS read the FS and put a pretty picture of those rules in front of the common user? One of my biggest wonders in computers has been the fact that the underlying FS determines what file names and such I have to juggle. That's kinda annoying. Why haven't we come up with an API to abstract this yet?
AB HOC POSSUM VIDERE DOMUM TUUM
Not only that, but what about the lusers who change the extension. They might want that picture to have motion so they rename "mekitty.png" to "mekitty.avi" and expect it to work. Or they want to import it into a word processor (one which doesn't read most picture formats) and they rename it to "mekitty.doc", then they send it to some "smart computer guy" and ask him to fix it. ...and if you have an OS or any programs which decifer the magic string, you have one hell of a time with that file...
Too much fun for me.
Most users will never settle for only alphanumerics/hyphens, and it's usually the user who has the filename problems. Especially where I am, where every user is wielding a 8-bit character map and lots of imagination. I still remember the horror days when I had to fight a loosing battle involving a Unix file server, sharing the same tree to MacOS and Win95 users with 8 bit filenames. Although things have gotten better with OSX/XP there's still room for improvement.
What kills me is Mac's Option-8 character - We (ab)use it regularly @ my place of work, and it drives me insane how tied we are to it. Not a good character to use if you are a CL whore such as myself :)
"Better to be vulgar than non-existent" -Bev Henson
Windows also reserved certain file names, like "con".
Oh, and that includes constructs like "con.c".
Even worse is if you are trying to write a CD-R or DVD-R. They have their own similar but not the same restrictions. file length and commas IIRC. PITA
what about ones that use an installer script (.pkg, .mpkg)?
Half of those install in places other than the Applications folder and tie into the BSD-like environment. The others can install files in the Library folders, and some do and some don't.
AmigaOS (to throw in another pre-Win95 system that support longer than 8.3-filenames) was case insensitive, too. In addition it used its Locales feature to match Files like "WÜRMER" and "würmer" or "école" and "ÉCOLE". Once I knew the Linux way of case sensitivity, I must admit that the Linux solution is the best, since you cannot possibly sort out all strange German, French, Icelandic,... whatever letters.
In unrelated thoughs, a problem with different filesystems is that it's hard to preserve the correct spelling of those Umlauts or accends. WÜRMER.EXE on VFAT easily translates to W?RMER.EXE on my ext3 Linux system. Ideas anyone?
I don't think they help much when using slow ssh sessions. I mean, they do help, but usually a "slow ssh session" is mainly about latency. That is, you could type a whole line of text and wait for it to be sent, but it would go through all at once when it did. Calling it "man" instead of "manual" to save three keystrokes is pointless, because you'll almost never have an ssh session where three keystrokes is faster than six. Just type as fast as you want, and wait for it all to go through.
If it did save time, you've got bigger problems -- "man" almost always returns a full screen of text, which (if it mattered, which it doesn't) is going to take a lot longer than waiting the extra three chars for "manual" instead of "man".
Don't get me wrong, I'm not suggesting we change it. Learning archaic commands and function names is something of a hazing ritual in the hacker community, and they're worth it for the inside jokes anyway -- "man woman" doesn't work with "manual".
Don't thank God, thank a doctor!
> In my mind Program Files is progra~1 and Microsoft is micros~1.
.INI files and registry keys.
Things get really nasty on international installs.
German Windows for example keeps applications in "C:\Programme\" which also translates to "C:\Progra~1".
Now, some software uses hard-coded paths and on German windows you often also find a "C:\Program files\" folder (usually empty or with just one program in it). This folder is "C:\Progra~2".
With this (not so uncommon) setup, imagine you want to make a backup. You go folder by folder, in alphabetical order. You'll back up "C:\Program files" first and "C:\Programme" second, because blank goes before the letter "m" in most alphabetical comparisons.
Later, you're going to restore to a blank harddrive. You'll restore "C:\Program files" first, and this will allocate "C:\Progra~1". Then you'll restore "C:\Programme" and this will allocate "C:\Progra~2".
Damn, it's exactly the wrong way. How could this happen?
Well, it happened to me with an IOMEGA backup product. Half of the software didn't work anymore, because it had the wrong path in their
Two lessons learned:
1) Don't trust IOMEGA products for backup.
2) Having transparent (=automatic) multiple names for files is evil. The long/short name stuff should have been implemented in a different way, that makes it less automatic and thus more controllable/predictable to the developpers.
Marc
Well, the practical stuff is basically this: Linux supports whatever you put in the file names, Nautilus supports both Latin-1 and UTF-8 file names. OS X insists on UTF-8 names, on file system level. MacOSX chokes if I unzip or scp or svn a file that has Latin-1 file names - either refuses to cooperate or truncates the names, as happens with Linux-burned CDs. Linux-burned Rock Ridge CDs work just fine in Mac (aside of the Latin-1 issue). Mac burns CDs using some weird (new?) variation of Rock Ridge that makes makes all files lower-case in Linux, and makes the files *appear* to have 512 bytes, in case I burn big .aiff files (big files, or a four-letter file name extension, take your pick, I'm not a filesystem expert), and requires quite a few funny mount options to make the file actually readable.
And Windows, which I don't use these days a whole lot but ocassionally still need to, seems to still have funny ideas about MYSTERIOUS spontaneous Capitalizations and other WEIRDD~1 stuff, though it's almost getting in control in new operating systems after getting introduced over a decade ago. Some oddnesses can still be seen every now and then.
And we complain that Windows is bloated? Linux (as an OS) now includes not only a web browser but an office suite, and IM client, development tools, and everything else we could want?
/bin and /lib. And generally, I can install packages -- not manually, but by choice -- to /usr. The difference between /usr and /usr/local has to do with a package manager, which doesn't really have a decent equivalent on Windows.
Generally, by "pieces of the OS", we're talking about stuff in
Don't thank God, thank a doctor!
Since I'll take your "I RTFA" summary as fact since "I haven't RTFA". There is at least one huge difference between Linux FS like ext2 or ext3 and Windows NTFS or FAT. Windows does not support paths longer than 256 (or 512?) characters. Once you hit that limit, the path is not accessible.
The scenerio is painfully obvious when you use something like GNU Arch (tla) under windows. It doesn't work because Windows cannot handle longer paths. Well, actually it CAN handle, but it doesn't thanks to the great backwards compatability. So, you can end up with paths you cannot delete easily. Yes, even in XP with latest updates.
The only work around in tla is to use the "compatability" or the 8.3 mappings of longer paths. Then your real path is longer than the limit, but your mangled path is shorter and file operations work again.
So to summerize,
Windows => long file names, hardcoded limit for paths
Linux => long file names, FS dependent paths lengths
-b.
You forgot about the ability to regurgitate the latest marketing spiel.
Package managers can uninstall programs too. ; )
That's a valid point of view as well.
"[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz
a file like.. kernel-image-2.2.14_Custom.1_i386.deb is very descriptive, but a pain to type all that.
The other thing that annoys me is file names tHat_USe_a_Mixture_oF.cASe especialy in linux where it must be exact.
waiting for ad.doubleclick.net
Ric Romero wanted for breaking news story on 'long filenames'! :-)
I imagine there are workarounds less kludgy than what I end up doing; but really it seems like you shouldn't have to worry about it at all - the spaces should be handled appropriately and automatically.
#DeleteChrome
-b.
Try to create con.txt or lpt1.txt on a windows box.... WTF ms-dos devices list: AUX,COM1,COM2,COM3,COM4,CON,LPT1,LPT2,LPT3,NUL
The article didn't mention it but there is an option for case sensitive HFS+. I tried it out and it worked as expected.
The article also mentions the "lowercase-hyphen rule", which I still pretty much employ. I still do it because I dislike quoting filenames on the command line. I also do it to make it easier to pick out file names from directory names, which I always title case, since I don't care for dircolors.
Why not something more sane like ~/Music/Nine Inch Nails/The Fragile/Right/03-Where is Everybody.ogg and ~/Music/Nine Inch Nails/The Fragile/Right/06-Starfuckers Inc.ogg to begin with and use the ID3 or OGG tag for exactly the use you're trying to squish into a single filename? There isn't an MP3 or Ogg player worth actually owning that can't read the tag, freeing you to use a more portable filename.
Help us build a better map!
I've been using linux for more than a few years now, but one thing I've always wanted is file extensions by default in programs. Too many times I forget to add them manually, it's just I wish the apps did.
.txt, but it erks me to always have to remember to add an extension.
Yes I know linux uses mime types but both can be beneficial. Here's a basic example, I have a dir as many do of various documents, and suppose I typed something in a plain text document a few years back and I just remember a keyword that will probably find it for me. When I do a search in gnome/kde using their respective search tools, it will search all text documents, OO, doc, pdfs etc. If I already know the information is in a text file, it would be nice to be able to put *.txt to speed up the search. Sure this works if I made sure before hand I named the file
Yes, the filesystem supports gigantic filenames, and yes, quite a lot of Windows supports those big filenames as well.
However, there's a lot of backward compatibility in the built in libraries, and a lot of this backward compatibility does *not* handle those long paths nicely. What's worse is that by not deprecating a lot of this functionality, most apps written for Windows still use these older calls. It's all tied in with Unicode and all the multi-byte string handling stuff as well.
This is one reason why developing for Windows kinda sucks, because while it's really easy to pop out a program quickly, it's very difficult to do it right and use only functionality that handles everything new and still maintains backward compatibility as well.
It doesn't help that a lot of Windows itself is written using the older functionality, thus making some parts handle really long filenames fine and other parts of it... err.. not so fine.
- Give a man a fire and he's warm for a day, but set him on fire and he's warm for the rest of his life.
I once had this big problem when I was working on a German Windows installation... Winamp going to right place while its plugins going to wrong ones.
I forgot to be anonymous.
Also, cmd.exe has a command history menu you can pop up by hitting F10 after you have entered a few commands in the window. I don't know if you have to have turned on command completion with TweakUI for this to work or not.
I never use this feature because Cygwin gives me what I want on Windows.
In DOS, ASCII 255 was a legal character for file names. You could type it by holding alt and pressing 255 on the keypad. That way you could get "spaces" in file names, and make them impossible for network admins to delete :)
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
You're absolutely correct; I should have said %PROGRAMFILES%.
"[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz
A company I consulted for was looking to get a domain name back in 1995-96. The president thought domain names had to be constrained to 8.3. They were trying out all sorts of bizarro 8.3 combinations, and eventually settled on one with vowels omitted.
Really, and the point of this article?
First it isn't even accurate about what long file names are or how they are used.
Linux and OS X files have more character(s)
This actually isn't true, NTFS supports UTF-16 and full Unicode support. Most *nix FS are UTF-8 are they not? And last time I checked, a 16bit Unicode FS, has a LOT more potential characters, and why even Wikipedia uses NTFS as the 'example' of a how a FS should handle Unicode, since NT's design goals for localization were centered around complete Unicode support.
Secondly, it improperly states that NTFS cannot be case sensitive. By default, NTFS is not case sensitive for the Windows subsystem, but it can be enabled, also the *nix subsystems that run on NT can and usually are case sensitive to comply with the *nix subsystem conventions.
Third, people paint long filenames as bad thing or something to be used sparingly, but with the search tools and command like tools, even in OSes like XP and OSX, using long filenames has no significant difference to a short filename that does not outweigh the ambiguous nature of using shorter filenames.
And even with all the incorrect information, this article explains or teaches what? Nothing...
We are a company that runs on Linux, Mac and Windows. We are having trouble sending Links in E-Mails that can be clicked on and that link to files in the Network... This is due to differences between Linux, Mac and Windows Network File Paths. Standardization here is really important! What do you know about this?
The article is far from complete in terms of the frictions between them... It might be right for the English speaking, but try to include latin characters etc...
Even though both Mac OS X and newer versions of linux use UTF-8 characters for filesystem names, the conversion break without external 3rd party tools. This is due to the UTF-8 on Linux being in normal form C whereas Mac uses their own Normal form D... So the problem goes far beyond mere regular letter problems...
For more info: http://j3e.de/linux/convmv/man/
Long.File.Names.Like.This.Remind.Me.Of.Doing.A.Sim ple.Task.In.Java
http://www.thirdrake.com - Best Webcomic of all time.
While Windows95 never supported anything beyond 255 characters, the VFAT directory entries could technically be a bit larger. The LFNs were present additionally to every standard 8.3 directory entry (32 bytes each), and were made up of blocks with 13 characters in each (UCS2 or UTF16). Additionally each block had an index number of which only 6 bits were allowed to be used (1..63 IIRC, check 'Interrupt List'), and therefore yields 63 x 13 = 819 characters for the long filename version.e #Directory_table
http://en.wikipedia.org/wiki/File_Allocation_Tabl
> You can also use non-printable characters in a file name, but I can't think of a good reason to do so.
Maybe because you live in an English-speaking country, and other people don't.
Nice article. Keep writing articles, and don't write any software, especially software for international users.
That's what meta-data is for. While I'm not a big fan of Mac OS Classic, this is one thing they did right: storing the file type in the file metadata (like the modification time, access time, and read/write permissions), instead of in the name.
I always felt it was too bad that OS X dropped the creator/owner types in favor of filename extensions, though I understand it was probably a good move from a compatibility standpoint. (That, and moving away from the resource/data fork model, made it much easier to transfer files among Windows, Mac, and *nix computers.) It felt like a step backward, though -- it would have been better in the long run if Windows and various Unix-like operating systems (and the filesystems they use) had added filetype metadata, rather than Mac OS dropping it.
You can kill the evil tilde with this small registry hack:
o l\FileSystem\NameNumericTail = hex:00
/. added spaces other than those around the = sign)
.3 extension entirely.
.html is NOT associated with Mozilla.
.jpg extension. However, if I omit the extension when I type the name, then it will add the correct one for the filetype. So a JPG never winds up named either just "something" with no extension, nor "something.jpg.jpg.jpg".
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Contr
(that's all one line, and beware of any
I do this on all my WinBoxen, because otherwise Windows fucks up my DOS filenames.
BTW, as several note below, DOS (and for that matter Windows) couldn't care less if a filename omits the
As to files that wind up named "something.jpg.jpg" and the like, that's an application misbehaviour, not a Windows issue. It can happen two ways:
Frex, if I save use Netscape to save a file that is named "something.htm" on the website, NS preserves the filename exactly. But Mozilla renames the file "something.htm.html" whether I like it or not, and it does this even tho
The other way it can happen is if the app isn't smart enough to check whether the user is typing in a recognised extension that is correct for the filetype, and/or whether the file already has an extension, so the app just blindly adds it.
As an example of more-intelligent behaviour, if I name a file "something.jpg" in Corel PhotoPaint, and save it as a JPG, PhotoPaint is smart enough NOT to tack on yet another
~REZ~ #43301. Who'd fake being me anyway?
Despite your naive assumption that something with "16" in it's name is better than something with "8", the facts are that UTF-16 cannot handle as many characters:
UTF-16 as originally designed handles 0xffff characters.
Because that was not enough characters, UTF-16 was modified to have "surrogate pairs". Usually claimed to now handle 0x10ffff characters, but in fact they fail to subtract the surrogate half-characters (0x800). Also this deleted the only plausable claim that UTF-16 is better than UTF-8, in that characters all are the same number of bytes long (it is in fact worse, because the variable-length characters are much more rare, so bugs in handling them are much less likely to be detected and thus more catostrophic when they do happen).
UTF-8 as originally designed handles 0x7fffffff characters.
Because of the UTF-16 braindamage, the standards for UTF-8 were modified to say that all encodings after 0x10ffff are illegal, so literally UTF-8 was downgraded to match UTF-16. It still is false to say that you can losslessly translate from UTF-8 to UTF-16, due to the surrogate pairs, so they are not equivalent even with this limitation.
The one positive benifit of the "Unix wars" was that it stopped a whole lot of politically-correct idiots from forcing "wide characters" on everybody, and thus Plan9's UTF-8 could take hold. Unfortunatly Microsoft completely ignored all the proof that wide characters were a very bad idea and went and did it themselves in Windows. Still not as bad as if Unix had done it too...
No, as the reply says, the 2nd installed will be ~2. It doesn't change them after the fact.
o l\FileSystem\NameNumericTail = hex:00
/. space in what should be "control" -- clearly /. needs a "no space added" hack!)
However, you can kill this nasty behaviour entirely with the nonumerictail registry hack, which I repeat from my post above:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Contr
(beware of the
This will NOT affect existing tilde'd filenames. And it works fine on all my WinBoxen, most of which also run DOS apps.
~REZ~ #43301. Who'd fake being me anyway?
Case insensitivity seems like a nice, useful feature. But, in the end, it causes more harm than good: "case" is a rather odd concept, limited to certain languages, and even within those, often not well defined. In English, you can sort of get away with it. In other languages using the Latin alphabet, changes in capitalization may change the spelling of a word, and which upper and lower case characters correspond to one another are language dependent. On the other hand, in languages other than English (and to a lesser degree even in English), upper and lower case characters really do convey different meanings. "White House" means something different from "white house", and even sounds different. And different systems may mean different and incompatible things by "case insensitivity", since there is no single well-defined standard.
Altogether, that's a Pandora's box that's not worth opening: what looked like a simple use-friendly feature, case insensitivity, turns into a localization nightmare that's even harder to explain to users than case sensitive file names.
Case sensitive file systems are the right way to go; UNIX got it right, Macintosh and Windows got it wrong. The usability benefits are slight, and the usability pitfalls and resulting system complexity are huge. For programming languages, this issue has largely been settled a couple of decades ago. It's time we get rid of case insensitivity in file systems as well.
...you suck at scripting.
...
Typical shell scripting idioms like:
for $each in *glob.pattern* ; do
command "$each"
mv "$each" "$(echo \"$each\" | sed -e s/stuff/replace)"
done
The only extra quoting necessary is in commands with variable substitution. And (while it may seem confusing), that syntax works even when the filenames have quotes internally. The double quotes identifies the contents to be treated as a single token with interpolation to be performed before passing on to ``command'', which is what you wanted.
Also the $() syntax is your friend. But remember to give it ""s too, you don't want it to expand it AND THEN tokenize it.
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
Convergent Technology's BTOS system had long filenames *way* before any of the three operating systems mentioned here...
s e
but_a_long_filename_was_a_real_freaking_pain_to_u
Needless to say filename issues are a frequent pain in the balls.
You have a SAMBA share containing 2,500 Windows profiles, you write a bash script to move them from one disk nearing capacity to a newly installed redundant volume with adequate capacity.
How many folders do you think you will find named "user.name's pictures"?
Different naming standards in different platforms is only slow news material if you're not nerdy enough ;)
1. the requirement the ".3" portion be satisfied, i.e., if you didn't give a ".3" extension, it wasn't valid.
untrue you could have files without an extention under plain dos.
2. the semantic mapping of the extension to filetype, WTF?
so they made the filetype part of the name so you could have identically named files of different types (e.g. the source and the binary of an app), seems sensible enough to me.
3. the implied (don't remember if it was canonical) semantic that no ".3" extension meant the file was a directory
directories were identified by a seperate attribute, as i said above you could have an extentionless file, you could also have a directory with an extention (though it was rare)
4. the case insensitive nature of file names
very much a personal preference thing this.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
Hey cool, I do this to:
Wanna be safe most of the time:
1) No spaces
2) Under 32 character filenames
3) Alphanumeric, underscore, period, or hyphen ONLY
4) Only a single period allowed.
5) must start with an Alphanumeric
6) not more than a single underscore, period, or hypen at a time in the series of characters. ie.: "poorly--named"
Windows is very funny when long directories and long filenames are used. However NTFS is able to handle up to 32k+ characters. I recently had to write a program to backup files with long names and deeply nested directories that were stored on a windows server. In windows the filenames and folders would never have been allowed but because the PC's saving the files to the server were running OS X they had no problems creating the files. my backups kept failing when traversing the deeply nested directories. I had to work around the problem by creating A network share to the folder I was backing up. then back up the files via the share. It worked great except for a small problem that SMB shares can only be up to 255 chars long. This effectively gave me up to 500+ characters of path. Fortunately it was enough to allow my program to backup the files. however I did have to lay down some rules for the OS X users to limit their directory depth.
It is official; Netcraft confirms: Linux is dying
One more crippling bombshell hit the already beleaguered Linux community when IDC confirmed that Linux market share has dropped yet again, now down to less than a fraction of 1 percent of all servers. Coming on the heels of a recent Netcraft survey which plainly states that Linux has lost more market share, this news serves to reinforce what we've known all along. Linux is collapsing in complete disarray, as fittingly exemplified by failing dead last in the recent Sys Admin comprehensive networking test.
You don't need to be a Kreskin to predict Linux's future. The hand writing is on the wall: Linux faces a bleak future. In fact there won't be any future at all for Linux because Linux is dying. Things are looking very bad for Linux. As many of us are already aware, Linux continues to lose market share. Red ink flows like a river of blood.
Ubuntu is the most endangered of them all, having lost 93% of its core developers. The sudden and unpleasant departures of long time Ubuntu developers only serve to underscore the point more clearly. There can no longer be any doubt: Ubuntu is dying.
All major surveys show that Linux has steadily declined in market share. Linux is very sick and its long term survival prospects are very dim. If Linux is to survive at all it will be among OS dilettante dabblers. Linux continues to decay. Nothing short of a miracle could save it at this point in time. For all practical purposes, Linux is dead.
Fact: Linux is dying
Try IsoBuster. It can usually read at least some stuff from a corrupted cd, if not everything. Googling for it works fine.
Nerd rage is the funniest rage.
HFS+ also allows leading and trailing spaces, for example you can have a file named " filename" or "filename "
And I got into trouble the other day mounting a volume from my PC on my Mac and creating a folder named "Misc." There was no problem accessing it on the Mac but Windows choked on it every time. I had to remount the volume on the Mac and rename it to get at the files inside it.
"Grab them by the pussy" -- President of the United States of America
TFA states, very early, Linux file names can be up to 255 characters long, and that's where I stopped reading it.
Um...
B$ uname -a
Linux ganymede 2.4.21 #13 Sun Aug 17 10:31:38 EDT 2003 i686 i686 i386 GNU/Linux
B$ rm *
B$ touch `seq -w 1 200|tr "\n" "_"`
B$ ls |wc -l
1
B$ ls |wc -c
801
One file, 800 character. I'd have posted the output of ls -l, but the slashdot lameness filter exploded.
Depends on the filesystem used.
Long file names in windows is kinda hokey. If you are at the command line, then you are stuck with the 8.3 format. Ending a directory name in "~1" is not my idea of long file name support.
in a shell script and pipe to it.
The 2nd -e is useful with left-hand brackets.
Except that it's no longer true. Windows itself is limited to 32,000 (or thereabouts) unicode characters, it's just the ANSI (instead of Unicode) Win32 file I/O functions are limited to 255 characters. See this, for the docs. (Okay, it's a little murky quite where the limits are - but certainly the NT Kernel and NTFS don't have this limitation; the Win32 layer may have it still, especially in the older API calls.)
Because you have to use the Unicode API instead of the ANSI API, there is varying support for long paths among windows programs. As an example, the version of Robocopy distributed with the Windows 2000 resource kit is limited to 255 character paths, but the version distributed with the Windows 2003 is limited to 32k paths.
It's not "their own" in the sense of not being part of the Unicode standard; both forms C and D are part of the standard. Mac OS X happens to be the only system I know of that uses form D, however.
Note that when the man page in question says that Darwin prevents the creation of files with names that aren't valid form D UTF-8 strings "at filesystem layer", "filesystem layer" refers to HFS+, not to the VFS layer; you can create files with names that aren't valid form D UTF-8 strings on UFS, for example. Also, attempts to create files with form C UTF-8 names on HFS+ will, as far as I know, be treated as attempts to create files with the equivalent form D UTF-8 names. The SMB client assumes UTF-8 file names and converts them to form C UTF-16 names over the wire, as that's what Windows prefers; VFAT and NTFS might do the same. The NFS client doesn't care - it just passes the bytes over the wire; what gets done with those bytes is up to the server.
Microsoft's .Net Framework uses descriptive filenames (ie: Microsoft.DirectX.Direct3DX.dll), and it's encouraged for all assemblies made by third parties, since the output filename defaults to the assemblies' namespace.
Sure, that's good enough as long as you don't ever have to touch either OSX or Windows. In that case, you don't have to worry about the restrictions, sometimes pathetic, of those systems. If you are not so lucky and don't read the rest of that single almost advert free page, you might bone your finder with the wrong characters or blow pass the windoze 256 path + name length limit. This advice is worth following:
For maximum portability, avoid using characters that are illegal in any of the operating systems.
His follow up advice about spaces is also worth while.
Friends don't help friends install M$ junk.
n/t
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
Yes. If you're a Slashdot reader, and you haven't figured out why people complain about Windows so much, then there's really nothing more that can be said to you.
http://outcampaign.org/
Alternate Data Streams are good place for file managers to cache their metadata about a file, since if the file is moved, the metadata moves with it, and if the file is deleted, so is the metadata. Does Explorer actually use ADS this way? I don't know.
http://outcampaign.org/
I have a poky script nsra to automatically rename spaces to underscores in every filename under the current directory. The companion script lcra renames README.TXT to readme.txt, etc, but leaves mixed-case filenames alone.
-- Ed Avis ed@membled.com
All this and not one complaint about the fact that OS X gives up too quickly when copying filenames too long for Windows over to a Windows share? I was hoping someone would post about this so I could see someone reply with a solution because I have yet to find one :(
The problem is that if you are copying a large number of files to a Windows share from a Mac and ONE of those files has too many characters for Windows then OS X gives up on the copying without giving you the opportunity to skip the file with the invalid name.
Has anyone found a solution? I would definitely be happy to have the option to skip files with long names and be able to continue copying the group of files I need. Bonus points if afterwards you get a report of the files that didn't copy so you can possibly rename them and copy them afterwards.
...unfortunately no one can be told what The Mat^H^H^HGoatse is...they must experience it for themselves...
Tell me honestly, when was the last time you actually saw 2 files in the same directory distinguished only by capitalization?
;-)
;-)
;-). You don't necessarily need to make this distinction in file names, but it's a lot more convenient if you can. Thus, if I make a directory containing definitions of terms, it would be handy if I could have both "apple.html" and "Apple.html". Granted, I don't need to have this, and I can always program around it. But forbidding me to use such file names just puts one more silly barrier in the way of Getting The Job Done, and adds to my frustration level. It's one more things that tells me that I should stick to a real unix-like system that doesn't throw such gratuitous stumbling blocks in my path.
;-)
Well, I don't recall the exact date, but it was within the last few days.
The files were in a site dealing with European classical music. In most of Europe, it's common to use case to indicate major/minor keys. Thus "Sonata in D" and "Sonata in d" mean D major and D minor, respectively. The files I saw had names like "Sonate_D.mp3" and "Sonate_d.mp3". This is an imminently sensible way for a European classical musician to name files, because it matches exactly their standard notation for such things.
(Actually, you'd usually want a few more characters, since some composers wrote more than one sonata in D or d, but you get the idea.
Now, you can say that this is a stupid way to name things, and you might be right. But musicians have never been known for intelligent notation. And as a programmer who deals with a lot of network issues involving people who don't always speak English too well, my reply is "It's not my job to tell people that their language is wrong; it's my job to implement things that work the way my users expect". In the above case, some musicians gave the files the obvious names, and it Just Worked. They didn't have to figure out why one of their files mysteriously disappeared, and the remaining file contained the wrong sonata.
Since there are a lot of uses of case distinctions in many languages, I'd prefer that my software implement the case distinctions that my customers are comfortable with. And if I'm making a decision on what to run on a server, I'm going to choose a system that doesn't impose a particular case policy on me. This is one of many reasons I'd choose linux or *BSD or Solaris for a server, but not OSX or MS-Windows. I don't need the hassle of an OS that imposes such policy decisions on me, contrary to what I know makes sense to my users. Yes, I can find a workaround, but why should I waste the time?
It's easy enough to come up with reasons that an English-speaking user might want to use case distinctions. Around here, we all know that "apple" and "Apple" mean different things (and one is a trademark so you'd better not misuse it
The unix world has long had a mantra: The OS implements mechanisms, not policies. Case (in)sensitivity is a policy, not a mechanism. As such, it properly belongs in the runtime libraries, where different groups of users can easily implement their own policies. It doesn't belong in the OS kernel, where a policy is imposed on all software and is very difficult to override if it's wrong for your application.
This was a very good design decision back in the 1970s, and it's still a good design. At least if you want to keep your programmers sane, and help them implement user-friendly apps. The kernel should treat a file name as a string of bytes, and not impose any interpretations or policies on what those bytes may contain. (The unix use of '/' is in fact a minor annoyance here, which I sometimes really wish Ken and Dennis hadn't done. But I understand the practical reasons why they did it, so I forgive them.
Of course, part of the issue here is that Microsoft and Apple have long thought that it is their job to impose policies on their developers. This isn't real
Those who do study history are doomed to stand helplessly by while everyone else repeats it.
Change is certain; progress is not obligatory.
Change is certain; progress is not obligatory.
This is wrong... OS X only accepts UTF-8 sequences, and will also convert them to Unicode NFD before sending them to the hd driver. This can be an issue with Linux since the favourite Unicode form there is NFC, so it might have problems with comparing.
OS X does accept colons, it's just that Finder and Carbon converts them to/from / for historical reasons.
For an article aiming at portability, I think they missed out on the biggest issues.