Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Linux/Mac/Windows File Name Friction

Hemos posted more than 8 years ago | from the like-doing-it-with-sandpaper dept.

638

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. "

cancel ×

638 comments

Sorry! There are no comments related to the filter you selected.

Long filename horror story (5, Funny)

suso (153703) | more than 8 years ago | (#15690668)

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.

Re:Long filename horror story (1, Funny)

Anonymous Coward | more than 8 years ago | (#15690690)

You = total pussy.

Re:Long filename horror story (2, Funny)

Jesus_666 (702802) | more than 8 years ago | (#15690771)

Of course you meant "You = totalpu.ssy" or "You = total~1".

Re:Long filename horror story (0, Informative)

Anonymous Coward | more than 8 years ago | (#15690772)

Those filenames are longer than the 31 character limit on Mac OS systems. You're lying.

Re:Long filename horror story (2, Informative)

NutscrapeSucks (446616) | more than 8 years ago | (#15690783)

MacOS was limited to 31 character names, so you're misremembering things.

Re:Long filename horror story (4, Funny)

suso (153703) | more than 8 years ago | (#15690820)

MacOS was limited to 31 character names, so you're misremembering things.

I have a bumper sticker on my car that says:

"I waste my jokes on the accuracy nazis on slashdot."

Re:Long filename horror story (1)

NutscrapeSucks (446616) | more than 8 years ago | (#15690839)

I wasn't trying to flame, but file name length is the topic of the story. The joke would have been better if you got it right.

Re:Long filename horror story (2, Interesting)

zsau (266209) | more than 8 years ago | (#15690899)

Even though others apparently claim you're joking, I personally am all for gratuitous words in file names. Some times I achieve this by gratitously deep folder heirarchies, but usually I just randomly add keywords to files. I mostly use a GUI, so it doesn't stress me out too much, but makes it much easier to find them two years later.

(I also like my music files to accurately contain the name of the track, so a song like "Where is everybody?" becomes "(maybe the artists name, album etc. -) 03 - Where is everybody?.ogg". Worse, if it's "Starfuckers Inc.", it becomes "06 - Starfuckers, Inc..ogg". It quite annoys me when I try to copy the files to my music player, which has a FAT-based filesystem.)

Re:Long filename horror story (5, Insightful)

mausmalone (594185) | more than 8 years ago | (#15690946)

Perhaps that's a bit long of a file name, but it's at least descriptive. I can't tell you how many times I've gotten files titled Agenda 01.doc when they should be more like Tech Committee Agenda 2006-05-01.doc -- it's not excessively long, but with a file name like that I know EXACTLY what's in that file.

Damn this is exciting! (1, Insightful)

windowpain (211052) | more than 8 years ago | (#15690669)

Slow news day?

Re:Damn this is exciting! (0)

Anonymous Coward | more than 8 years ago | (#15690689)

Yep

Re:Damn this is exciting! (0)

Anonymous Coward | more than 8 years ago | (#15690964)

Or, exodus to Digg.

help!!! (-1, Offtopic)

Anonymous Coward | more than 8 years ago | (#15690674)

ot:

can someone recommend a free alternative to windows media center?

thanks-

rob the knob

Re:help!!! (0)

Anonymous Coward | more than 8 years ago | (#15690694)

Similarly off-topic: XMMS for Linux of WinAmp for Windows

Re:help!!! (-1, Offtopic)

Anonymous Coward | more than 8 years ago | (#15690725)

Have you tried MythTV [wikipedia.org] ?

Re:help!!! (0, Offtopic)

rtyall (960518) | more than 8 years ago | (#15690782)

You can use Media Portal [team-mediaportal.com] if you're on XP, or Knoppmyth [mysettopbox.tv] if you want a completely different OS.

Tagging (-1, Offtopic)

kevin_conaway (585204) | more than 8 years ago | (#15690680)

File names aside, is there a good way to "tag" files (generic metadata) on Windows or Linux? I know some linux filesystems support extended attributes, but not all of them and even those that do may not have it enabled.

Show of hands, those of you that run a Linux machine, do you have extended attributes enabled on your filesystem

Beagle requires xattrs (1)

user9918277462 (834092) | more than 8 years ago | (#15690703)

Beagle [beagle-project.org] 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.

Re:Tagging (2, Informative)

pla (258480) | more than 8 years ago | (#15690887)

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.

c:\progra~1\Micros~1\Powerp~1 (2, Interesting)

stupidfoo (836212) | more than 8 years ago | (#15690686)

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.

Re:c:\progra~1\Micros~1\Powerp~1 (2, Interesting)

mrjb (547783) | more than 8 years ago | (#15690749)

When you use cmd.exe for a command line interpreter, it makes more sense to type

cd prog*\mic*

Not only will this work, it will also work on other platforms, and it will also keep working when the silly ~1 convention is abandoned.

Re:c:\progra~1\Micros~1\Powerp~1 (4, Insightful)

stupidfoo (836212) | more than 8 years ago | (#15690830)

The problem with that is that it goes to the first one in alphabetical order. So if you had c:\program files\Microsaucer and c:\program files\Microsoft it will go to microsaucer.

Re:c:\progra~1\Micros~1\Powerp~1 (2, Informative)

Anonymous Coward | more than 8 years ago | (#15690941)

Not so. It goes to the first created file. So if you create microsauer, then microsoft, but delete microsauer later, microsoft will stay as Micros~2

Re:c:\progra~1\Micros~1\Powerp~1 (2, Interesting)

cortana (588495) | more than 8 years ago | (#15690943)

Ugh, I hate that behaviour. I wish it would use readline's default behaviour. The alternatives ('microsoft' and 'microsaucer') would be listed, and after that the original prompt completed up to 'micro' would appear.

(Readline is the line input library used by Bash and lots of other GNU/Linux software that presents a command-line interface).

C:\P[tab]\M[tab]\P[tab] (1)

The MAZZTer (911996) | more than 8 years ago | (#15690797)

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.

Re:c:\progra~1\Micros~1\Powerp~1 (2, Interesting)

Delirium Tremens (214596) | more than 8 years ago | (#15690809)

Careful with that because if you install -- say -- a software called ProGrabber in c:\, it now becomes Progra~1 and Program Files becomes Progra~2.

Re:c:\progra~1\Micros~1\Powerp~1 (5, Funny)

kripkenstein (913150) | more than 8 years ago | (#15690818)

Of course - this is a feature, not a bug.

Henderson_Presentation_2005.doc is HENDER~1.doc,
Henderson_Presentation_2006.doc is HENDER~2.doc,
Henderson_Presentation_2006 (unedited).doc is HENDER~3.doc.

Clearly, we are reaping the benefits of a well-thought-out platform here.

Re:c:\progra~1\Micros~1\Powerp~1 (1)

Bill, Shooter of Bul (629286) | more than 8 years ago | (#15690868)

Autocomplete via Tab key was only made avilible wint winxo's cmd.exe. Prior to that the tildas were the way to go for command line, for boxes that I didn't just install Freedos command.exe which allowed tab completion.

Ouch (0)

Anonymous Coward | more than 8 years ago | (#15690692)

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.

Re:Ouch (3, Informative)

chrismcdirty (677039) | more than 8 years ago | (#15690747)

Did you somehow miss the link? It basically said to remove files with a preceding '-' (-filename) you do 'rm -- -filename' or 'rm ./-filename'. And to remove a file with unprintable characters try 'rm file?with?unprintable?characters'.

Several things missing (1)

WindBourne (631190) | more than 8 years ago | (#15690828)

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.

Re:Several things missing (2, Funny)

kernelfoobar (569784) | more than 8 years ago | (#15690877)

*nix is much longer and able to go much deeper in the path.

I know there's a joke in there somewhere...

I RTFA (4, Insightful)

grasshoppa (657393) | more than 8 years ago | (#15690700)

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.

Re:I RTFA (5, Funny)

rtyall (960518) | more than 8 years ago | (#15690730)

I've just heard that all 3 Operating Systems support reading CDRoms? Is this true, can anyone confirm this revelation?

Re:I RTFA (1)

Billosaur (927319) | more than 8 years ago | (#15690736)

Tada! Two sentances. I imagine, were I a perl coder, I could have done it in half of one, but there you go.

Speaking as a Perl coder, I strongly obj...

Re:I RTFA (1)

99BottlesOfBeerInMyF (813746) | more than 8 years ago | (#15690740)

Linux is case sensitive, the others are not.

Hopefully you meant, OS X is case sensitive, the others are not?

Re:I RTFA (2, Informative)

Anonymous Coward | more than 8 years ago | (#15690790)

err... no.

linux et,al. == case sensitive
windows == case insensitive
OSX == case preserving

Try to keep up.

Re:I RTFA (1)

JM Apocalypse (630055) | more than 8 years ago | (#15690795)

10.4 is case sensitive, earlier versions are not. The author has probably never touched a mac.

Re:I RTFA (2, Informative)

mrchaotica (681592) | more than 8 years ago | (#15690851)

OS X is not case sensitive by default. It is case preserving, meaning that "Foo.txt" will still be "Foo.txt" when you move it or whatever (unlike in Windows, where it could turn into "FOO.TXT", but both names are still exactly the same file. Beware of this when copying files from a Linux (or otherwise case sensitive) filesystem to a Mac!

Now, OS X does have the option to use case sensitive HFS+ (or UFS, for that matter), but last I heard either is likely to cause problems if you try to use it as the root volume (i.e. the one the OS is installed on).

Re:I RTFA (5, Informative)

kimvette (919543) | more than 8 years ago | (#15690940)

Actually all three can be case sensitive.

Linux always is, by default (I don't know if you can make it otherwise without a LOT of hacking).

Windows: it is case "retentive" by default (it remembers cases as typed) but not case sensitive. It (full case sensitivity) can be enabled through a registry hack or two, or by selecting the "enable case sensitivity" option when installing SFU, at the cost of possibly breaking backwards compatibility with many applications.

Mac: OS 9 (and earlier) were case retentive only. OS X is case retentive (no sensitive) by default, however, if you install on a UFS filesystem it will become case sensitive, and just as with Windows, possibly breaking backwards compatibility with many applications.

spaces bad, special chars bad (5, Interesting)

yagu (721525) | more than 8 years ago | (#15690704)

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:

  1. the requirement the ".3" portion be satisfied, i.e., if you didn't give a ".3" extension, it wasn't valid.
  2. the semantic mapping of the extension to filetype, WTF?
  3. the implied (don't remember if it was canonical) semantic that no ".3" extension meant the file was a directory
  4. the case insensitive nature of file names
  5. etc. (or should I say, .etc)

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!)

Re:spaces bad, special chars bad (5, Insightful)

Chris Graham (942108) | more than 8 years ago | (#15690751)

You have some good points, but I really can't agree with two of your complaints... "the semantic mapping of the extension to filetype, WTF" It seems far better to me than mime-types or magic strings. Mime-types fail due to not being actually encoded on-filesystem, and magic strings require users to use a hex editor to try and identify an alien file type. "the case insensitive nature of file names" Case sensitivity is a big usability issue for people, so burdening the few (the programmers) so that the majority (the users) don't get confused, is a fair trade of IMHO.

Re:spaces bad, special chars bad (4, Informative)

vadim_t (324782) | more than 8 years ago | (#15690852)

I refer you to the file(1) command:
vadim@gadget ~/src/ac/src/viewer $ file *
Makefile.am: ASCII make commands text
image_list.c: ASCII C program text
image_list.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped
images.c: ASCII English text
images.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped
mapview.c: ASCII English text
mapview.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped
serverconn.c: ASCII C program text
serverconn.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped
viewer.c: ASCII English text
viewer.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped
As for case sensitivity, it's a seriously thorny issue due to some languages that have lossy upper/lower case conversion.

Re:spaces bad, special chars bad (1)

radish (98371) | more than 8 years ago | (#15690962)

And there's the problem:

images.c: ASCII English text

Great. It's "English text". Well, actually no it's not. It's C source code. I notice that you still have ".c" on the end of your filenames - surely that's redundant? Or maybe not.

Until file(1) can tell the difference between C code and Java code and a letter to my grandmother it's not so useful.

Re:spaces bad, special chars bad (1)

farnz (625056) | more than 8 years ago | (#15690985)

Mime types could be encoded on-filesystem if FS designers chose to (Freedesktop.org has a specification for doing so in a cross-desktop fashion [freedesktop.org] if you're using a UNIX with extended attributes). In any case, mapping files to file types by extension has issues to do with user training and multiple extensions (in particular, if I send you Important.jpg.vbs, which extension are you doing to pick on for the filetype, and which one is the system going to use? The wrong answer results in unexpected behaviour, which some Windows malware [f-secure.com] has exploited).

I agree that case-insensitivity is nice when working in English; however, in Arabic, short-vowel insensitivity would be more useful. In German, you have the complexity of ß versus SS versus ss. French requires you to ignore some accents. In short, the rules for each language are different, and on Windows 98, I had a few problems with foreign colleagues creating file names I couldn't handle (until we agreed on all-uppercase, English only names), because the two filenames were identical to Windows 98 English edition, but not to their foreign edition.

The point at which case sensitivity should be fixed is the point at which an application is prompting for a filename, not lower. If you're using tab-completion, I can do (locale-specific) processing to determine other plausible filenames, and print them for you to choose from. If you're using a GUI application (far more common), I can do case-insensitive handling of typed filenames, and highlight the file you've selected in a dialog box. I can even prompt you when you're creating two files with names that only differ in case, so that you can't do that accidentally. Any lower level, and you get into trouble with different languages having different case sensitivity rules.

Re:spaces bad, special chars bad (0)

Anonymous Coward | more than 8 years ago | (#15690798)

5. etc. (or should I say, .etc)

No, you shouldn't.

Re:spaces bad, special chars bad (4, Informative)

1u3hr (530656) | more than 8 years ago | (#15690804)

the requirement the ".3" portion be satisfied, i.e., if you didn't give a ".3" extension, it wasn't valid.
the semantic mapping of the extension to filetype, WTF? the implied (don't remember if it was canonical) semantic that no ".3" extension meant the file was a directory
Not true. I used names with no extension for my Wordstar files back in DOS days. Since that's what most of my files were, I made that the simplest. Directories usually had no extension, but you could have if you wanted (some programs did that for their private data).

Winows 9x and above though do enforce rules on extensions; but worst of all, hide some, or all, of them by default. Thus Anna-Kournikova.jpg.exe. The old Mac OS had it right, the filetype flags were not user-created or normally visible, though you could get tools to hack them if you wanted.

Re:spaces bad, special chars bad (1)

Eivind (15695) | more than 8 years ago | (#15690832)

unix also has "anything goes", but a strong sense of "not everything is wise".

Under ext3, Linux, all of the following are valid filenames:

  • "foo bar"
  • "-rf"
  • "*"
  • "\ ?"
  • " "
  • "foo\bar.*"

Don't get me started on the havoc newbies manage to make when trying to deal with suchlike. In general, people know this will blow up the first time someone tries a naive script, and tend to avoid all of it. The only thing borderline common is filenames with spaces in them, even this breaks some scripts, but arguably those scripts are broken anyway.

Re:spaces bad, special chars bad (1)

djmurdoch (306849) | more than 8 years ago | (#15690855)

1. the requirement the ".3" portion be satisfied, i.e., if you didn't give a ".3" extension, it wasn't valid.

As far as I know that was never true in DOS/Windows, though some applications may have done that.

2. the semantic mapping of the extension to filetype, WTF?

That bothered me at first, but it's a pretty nice convention to follow, so why not build it into the shell?

3. the implied (don't remember if it was canonical) semantic that no ".3" extension meant the file was a directory

That was only a convention.

4. the case insensitive nature of file names

I'm a native English speaker, so I don't mind this. English sometimes uses case to change the meaning of a word, but more often it's used to indicate something about the usage. I think Unix (and C, etc.) got this one wrong.


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.


You're talking about spaces in filenames, etc? Those were always possible in Unix; why didn't you write your code to handle them properly? ;-)

Options to show extension, defaults to hide extensions,

No question, MS definitely got that one wrong. But they were probably motivated by your complaint number 2: they just didn't have anywhere to hide the type marker in the file or extended attributes, so they put it in the extension and then hid the extension. Bad decision.

Does someone have a problem or two? (-1, Troll)

Richard_at_work (517087) | more than 8 years ago | (#15690716)

Is this anything other than an attempt to dis Windows for no other reason than 'Because'?

Re:Does someone have a problem or two? (1)

Rik Sweeney (471717) | more than 8 years ago | (#15690757)

Is this anything other than an attempt to dis Windows for no other reason than 'Because'?

Nope.

HTH.

Richard
xxx

File servers! (5, Informative)

WPIDalamar (122110) | more than 8 years ago | (#15690728)

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.

Re:File servers! (1)

Rosyna (80334) | more than 8 years ago | (#15690759)

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.

Which is always the issue. Windows is the weakest link. Services for Macintosh (now deprecated) is the thing that changes the names to be "mac safe" even though the idea of "mac safe" has long since changed since SfM was created. "Luckily" SfM is gone in Vista.

Re:File servers! (1)

NutscrapeSucks (446616) | more than 8 years ago | (#15690824)

Well, SfM has one set of problems, but the OS X SMB client has another set, so it's not definite which is better.

from the like-doing-it-with-sandpaper dept. (1)

Megaweapon (25185) | more than 8 years ago | (#15690732)

TMI Hemos!

NTFS WTF? (1)

Durandal64 (658649) | more than 8 years ago | (#15690733)

Windows file names can be up to 255 characters, but that includes the full path.
Holy shit is this true? That seems like a brain-dead limitation to have in the year 2006.

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.

Re:NTFS WTF? (1, Insightful)

fruity_pebbles (568822) | more than 8 years ago | (#15690850)

NTFS paths can be up to 32767 characters. Or so i read [wikipedia.org] - I'm too lazy to try it myself.

Re:NTFS WTF? (1)

ebh (116526) | more than 8 years ago | (#15690900)

Yes, it's true, and it really kills you in ClearCase, where you might have a file name like M:\some_view\some_vob\src\deep\path\to\file@@\main \some_branch\some_other_branch\1.

Re:NTFS WTF? (1)

amliebsch (724858) | more than 8 years ago | (#15690904)

Holy shit is this true?

No.

Re:NTFS WTF? (1)

EnsilZah (575600) | more than 8 years ago | (#15690981)

Heh, i recently came across that problem, i was trying to extract some zip files into an already long path and i kept getting errors on some of the files, took me a while to realize that the path of the extracted files was longer than windows allows.

Unusual characters in filenames (1, Interesting)

Rik Sweeney (471717) | more than 8 years ago | (#15690734)

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.

Re:Unusual characters in filenames (1)

arose (644256) | more than 8 years ago | (#15690837)

rm -- -

Re:Unusual characters in filenames (2, Informative)

JanneM (7445) | more than 8 years ago | (#15690844)

As a quick tip, "rm -- filename" would have worked; it makes rm not parse the filename in any way whatsoever.

Re:Unusual characters in filenames (1)

Zoxed (676559) | more than 8 years ago | (#15690871)

> "rm -- filename" would have worked; it makes rm not parse the filename in any way whatsoever.

IIRC the "--" is not an command specific feature, but is a feature of the bash shell (and probably others).

Re:Unusual characters in filenames (1, Informative)

Anonymous Coward | more than 8 years ago | (#15690928)

IIRC the "--" is not an command specific feature, but is a feature of the bash shell (and probably others).

No, it is a feature of getopt(3).

Re:Unusual characters in filenames (5, Informative)

Bogtha (906264) | more than 8 years ago | (#15690845)

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 -

That is what the -- option is for. It signifies that there will be no further options, so anything following it that starts with '-' will be interpreted as a filename. rm -- -funny-named-file will do the trick.

Re:Unusual characters in filenames (0)

Anonymous Coward | more than 8 years ago | (#15690847)

Use double-dash. For a file named '-oldname':

mv -- -oldname newname

Re:Unusual characters in filenames (2, Funny)

mjm1231 (751545) | more than 8 years ago | (#15690865)

That reminds me of the story about the time I learned to specify the path to the file I was deleting, such as:

rm /home/someuser/-file

Or even

rm ./-file.

Re:Unusual characters in filenames (1)

Alranor (472986) | more than 8 years ago | (#15690876)

rm -- -whateveritwasyoucalledthefile

or

rm ./-whateveritwasyoucalledthefile

Re:Unusual characters in filenames (1)

limbostar (116177) | more than 8 years ago | (#15690878)

Lots of people have mentioned the double-dash that makes getopt (the argument processor that rm uses) stop processing flags. But there's a simpler solution:

rm ./-

Since the dash is no longer first, it's not confused with a command.

(Typed with -v to evade the lameness filter.)

Re:Unusual characters in filenames (1)

NightWhistler (542034) | more than 8 years ago | (#15690881)

If you can't remember the other tricks, Midnight Commander (http://www.ibiblio.org/mc/) is your friend.

Should be installed by default on most Linux distros, and doesn't require X.

Re:Unusual characters in filenames (1)

mrchaotica (681592) | more than 8 years ago | (#15690890)

Did you try putting a " -- " before the filename? That's (usually) the switch used to tell the program to stop interpreting arguments as switches.

Re:Unusual characters in filenames (0)

Anonymous Coward | more than 8 years ago | (#15690897)

me@test:~$ rm -bla
rm: invalid option -- b
Try `rm --help' for more information.
me@test:~$ rm -- -bla
me@test:~$

Re:Unusual characters in filenames (1)

bsantos (655278) | more than 8 years ago | (#15690906)

In case it happens again, most of cli utils use the -- to know that if any other - shows up after it, it is not an option. Don't know if it is something about the parser lib used, so that all the apps that use it, work that way, or a design feature. It should work with mv, cp, rm.

Re:Unusual characters in filenames (0)

Anonymous Coward | more than 8 years ago | (#15690908)

Solution:

$ rm -- -weirdfile
(-- tells the option parser to stop there)
or
$ rm ./-weirdfile
(first character is . so it doesn't look like an option)

Re:Unusual characters in filenames (1)

TheOrquithVagrant (582340) | more than 8 years ago | (#15690914)

I've always considered this to be a borderline bug, since this also happens in wildcard expansion. If you do a "command *" in a directory where there are files beginning with a -, the wildcard will expand in a way that makes the command take the filename of file beginning with - as an option/argument. I've never found any "evil" way to exploit this, but it's always bothered me a bit.

Re:Unusual characters in filenames (1)

roemcke (612429) | more than 8 years ago | (#15690916)

Huh.. How could this be modded interesting without someone posting the solution?

rm -- -foo

`man rm' is your friend.

Re:Unusual characters in filenames (0)

Anonymous Coward | more than 8 years ago | (#15690918)

1) Use \ to protect
2) Use enclosing quotes to make literal (though grep doesn't like it. you can only grep on a charstring beginning with - if there is another character before it
3) As you did, remove using a GUI

Re:Unusual characters in filenames (1)

Constantine Evans (969815) | more than 8 years ago | (#15690921)

Using ./-filename instead of -filename should work in these cases.

Re:Unusual characters in filenames (0)

Anonymous Coward | more than 8 years ago | (#15690967)

Most unix command-line tools stop parsing arguments as filenames after a double-dash, e.g.:
rm -- -foofile
will delete the file `-foofile.' Just to let you know.

- chris_eineke

Any way to turn off Joliet support in Windows XP? (4, Interesting)

esnible (36716) | more than 8 years ago | (#15690739)

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.

Re:Any way to turn off Joliet support in Windows X (3, Insightful)

GotenXiao (863190) | more than 8 years ago | (#15690956)

Well, if MS hadn't decided to use \ as a directory separator, you could just backslash it. But no. MS had to be retarded.

If this had been fark... (1, Insightful)

Siberwulf (921893) | more than 8 years ago | (#15690766)

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.

Bah - OS Vendor support of long filenames (5, Insightful)

Rauser (631244) | more than 8 years ago | (#15690769)

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.

What about standards? (4, Interesting)

3gm (718785) | more than 8 years ago | (#15690777)

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.

Article is incorrect (5, Insightful)

joshv (13017) | more than 8 years ago | (#15690780)

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.

Re:Article is incorrect (1)

nstlgc (945418) | more than 8 years ago | (#15690986)

No idea how they did it, but XP _will_ complain if the complete path+filename exceeds 255 characters. It's the reason I stopped using My Documents alltogether.

Who gives a shit that linux supports long names (-1, Troll)

Clockwurk (577966) | more than 8 years ago | (#15690788)

when all the folders are 3 letter abbreviations and are found in multiple places. On windows, well behaved programs go in the aptly named "Program Files"; on OSX they go in "Applications"; on linux they go in /usr/bin or is it /bin or is it /local/bin or /wtf.

At least windows supports long enough file names to call their help files "help" and not "man".

Re:Who gives a shit that linux supports long names (1)

vadim_t (324782) | more than 8 years ago | (#15690885)

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.

Re:Who gives a shit that linux supports long names (0)

Anonymous Coward | more than 8 years ago | (#15690969)

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:.

Re:Who gives a shit that linux supports long names (2, Informative)

mrchaotica (681592) | more than 8 years ago | (#15690972)

On windows, well behaved programs go in the aptly named "Program Files"

No, they go in "C:\Program Files" and the Registry and one or more users' "C:\Documents and Settings\%USERNAME%\Application Data" folder.

on OSX they go in "Applications"

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.

on linux they go in /usr/bin or is it /bin or is it /local/bin or /wtf

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").

Amiga (2, Insightful)

Dan East (318230) | more than 8 years ago | (#15690823)

Amiga has had long filename support since it was first released in 1985.

Dan East

News (1, Flamebait)

spykemail (983593) | more than 8 years ago | (#15690825)

news - plural noun - information about recent events or happenings.

It_s not as if (1, Funny)

Anonymous Coward | more than 8 years ago | (#15690827)

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_

Best 8.3 filename mockery (5, Funny)

thatguywhoiam (524290) | more than 8 years ago | (#15690834)

The ad that Apple ran, back when Windows 95 launched:

C:ONGRTLNS.W95

Net Ho (1)

ArcherB (796902) | more than 8 years ago | (#15690902)

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.

Where's the !? (2, Informative)

Rurik (113882) | more than 8 years ago | (#15690929)

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.

Re:Where's the !? (2, Informative)

vadim_t (324782) | more than 8 years ago | (#15690980)

You just escape it with a \, like this:
vadim@gadget ~/tmp $ touch \!hi
vadim@gadget ~/tmp $ ls
!hi
vadim@gadget ~/tmp $ rm \!hi

Flexibility of *NIX (1)

heffrey (229704) | more than 8 years ago | (#15690983)

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!
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?