• foo (unregistered) in reply to Carl
    Carl:
    Meh:
    Carl:
    And "extensions" are another WTF. If you want to store some metadata about a file, store it in the file system's metadata place, sometimes known as a directory.

    Are you saying you store your file extensions somewhere other than in the directory entry?

    I'm suggesting they should be a separate attribute in the directory, not part of the name. See Jeff's comment on attribute overloading, above, or any book on data modeling, for why you don't store two attributes in one data element.
    Except for the little problem that you often have several files with the same base name (foo.c, foo.h, foo.o, foo or foo.exe; or foo.tex or foo.doc and foo.pdf; etc.). Even if you had a file system that allowed files to share the same name, it would still be a mess for the user or programs to find the right one. So while perhaps not optimal from a data modeling point of view, it's a pragmatic solution that works.
  • foo (unregistered) in reply to chubertdev
    chubertdev:
    So what's on the iPhone isn't just a drive with a bunch of ones and zeroes on it?
    The DRM, I suppose.
  • Meep (unregistered) in reply to Tom
    Tom:
    pkmnfrk:
    Tom:
    Kasper:
    press and hold the home key while the phone is connected to a computer or a Mac
    You have an odd conception of "or".
    Kasper:
    ...with iTunes installed.
    Wait, what? You have to have iTunes to manage your iPhone? WTF???
    Um, yes? It lets you backup your phone, install updates, copy files and apps, etc. Or, do you expect Windows to be able to do this by itself?
    My computer (Linux, if you care) can backup files, install files, copy files and apps etc. to any USB device without extra software. It is one of the simplest programs that can be written: read byte, write byte, repeat...

    Uh huh. Because on OS X, I can actually most things with a (reasonably) simple recursive copy. In Linux it's more like fire up aptitude, which will call into apt-get, which is a whole mess of python, so there's a whole virtual OS being emulated there. That, in turn, is contacting a whole system of incredibly involved web services to manage the distribution of content, let alone all the testing involved in making sure that stuff you download has a reasonable chance of working.

    If you want to be smug about using Linux, at least try to learn how it works.

    But yeah, why would you need a music app to manage your phone? To load all the vital ringtones perhaps?

    Really? I thought we were done with the whole "music and video are multimedia and it's all really just content" debate back in the 80s. Who fucking cares what it's called, it's a content delivery system that happens to play music.

  • (cs) in reply to Carl
    Carl:
    Why is Chrome asking about the "standard extension" in the first place? Isn't Chrome a web browser?

    (And "extensions" are another WTF. If you want to store some metadata about a file, store it in the file system's metadata place, sometimes known as a directory. Don't store metadata in the file name. I mean you don't store the last modified date in the file name do you? Or the permissions?)

    Welcome to Chrome OS. Being different by doing things exactly the same way...

  • Meh (unregistered) in reply to Carl
    Carl:
    Meh:
    Carl:
    And "extensions" are another WTF. If you want to store some metadata about a file, store it in the file system's metadata place, sometimes known as a directory.

    Are you saying you store your file extensions somewhere other than in the directory entry?

    I'm suggesting they should be a separate attribute in the directory, not part of the name. See Jeff's comment on attribute overloading, above, or any book on data modeling, for why you don't store two attributes in one data element.

    Ah. So it should be stored at a fixed position in the directory entry independent from the filename. Maybe we could go back in time and set aside, let's say, three bytes in the FAT directory entry for this "file type" metadata. Perhaps at an offset of 8 bytes from the beginning of the entry. Wouldn't want to use too much space; storage was expensive back then.

    Of course, you might want some way to distinguish between the text file called "foo" and the executable file called "foo". You know, like how on VMS sometimes you need to reference a specific version of a file by typing a semicolon and the version number at the command line. Maybe you could do something similar and separate it from the filename with some sort of punctuation.

    It sure would be nice if they'd done something like that, wouldn't it?

  • Len (unregistered) in reply to foo
    foo:
    Except for the little problem that you often have several files with the same base name (foo.c, foo.h, foo.o, foo or foo.exe; or foo.tex or foo.doc and foo.pdf; etc.). Even if you had a file system that allowed files to share the same name
    If your goal is to group some similar or related files together somehow, you can, you know. They can even share (part of) the same name:

    foo/c, foo/h, foo/o, foo or foo/exe; or foo/tex or foo/doc and foo/pdf

    Too bizarre to imagine?

  • (cs) in reply to Len
    Len:
    foo:
    Except for the little problem that you often have several files with the same base name (foo.c, foo.h, foo.o, foo or foo.exe; or foo.tex or foo.doc and foo.pdf; etc.). Even if you had a file system that allowed files to share the same name
    If your goal is to group some similar or related files together somehow, you can, you know. They can even share (part of) the same name:

    foo/c, foo/h, foo/o, foo or foo/exe; or foo/tex or foo/doc and foo/pdf

    Too bizarre to imagine?

    he's just a contrarian that's not worth paying attention to.

  • foo (unregistered) in reply to Len
    Len:
    foo:
    Except for the little problem that you often have several files with the same base name (foo.c, foo.h, foo.o, foo or foo.exe; or foo.tex or foo.doc and foo.pdf; etc.). Even if you had a file system that allowed files to share the same name
    If your goal is to group some similar or related files together somehow, you can, you know. They can even share (part of) the same name:

    foo/c, foo/h, foo/o, foo or foo/exe; or foo/tex or foo/doc and foo/pdf

    And this serves to remove the metadata (file type) from the file name exactly how?

  • AndyC (unregistered) in reply to Carl

    [quote user="Carl"] Are you saying you store your file extensions somewhere other than in the directory entry? [/quote]I'm suggesting they should be a separate attribute in the directory, not part of the name. See Jeff's comment on attribute overloading, above, or any book on data modeling, for why you don't store two attributes in one data element.[/quote]

    And then you want to give the file to someone else, via one of the numerous file transfer protocols which have existed for decades (some even pre-dating DOS + Windows) that have no concept for transferring said metadata. Which means the receiver gets a big binary blob and absolutely no clue what they're supposed to do with it.

    Anyone who used a Mac before Apple finally took the pragmatic approach and just adopted file extensions knows how deeply stupid that sort of system is when it operates in complete isolation.

  • geert (unregistered) in reply to Jeff
    Jeff:
    Dave:
    In Staples, when a product cannot be sold yet, the price in the system is 9999.99.
    No, no, wrong, wrong, WRONG! This is known as attribute overloading. As in, this attribute is the price, except when it isn't. It results in all sorts of bug-prone funky logic everywhere except the two places that forget to jump through the special hoops, giving us WTFs like today's.

    This was almost tolerable back in the COBOL days when two bytes cost more than your lunch. But anyone who's still doing it today is, well, simply incompetent to design data structures.

    Last time I was at a (Dutch) Staples shop they still seemed to use a system dating from the COBOL age. So I guess they actually never rethought their data structure at all...

  • Len (unregistered) in reply to foo
    foo:
    Len:
    foo:
    Except for the little problem that you often have several files with the same base name (foo.c, foo.h, foo.o, foo or foo.exe; or foo.tex or foo.doc and foo.pdf; etc.). Even if you had a file system that allowed files to share the same name
    If your goal is to group some similar or related files together somehow, you can, you know. They can even share (part of) the same name:

    foo/c, foo/h, foo/o, foo or foo/exe; or foo/tex or foo/doc and foo/pdf

    And this serves to remove the metadata (file type) from the file name exactly how?
    It doesn't. You said you wanted a collection of related files that shared part of their name. You can do that. You don't need a "file type extension" to do that.

  • Carl (unregistered) in reply to AndyC
    AndyC:
    you want to give the file to someone else, via one of the numerous file transfer protocols which have existed for decades (some even pre-dating DOS + Windows) that have no concept for transferring said metadata.
    So we're stuck with all bad design decisions for the next hundred years? After 1980, nobody is allowed to invent better protocols /cough/ HTTP /cough/?
  • David (unregistered) in reply to urza9814
    The fact that it's on a Beethoven playlist would probably be a WTF as well

    I think pandora intentionally pushes film scores on classical seed stations because its the only thing remotely close to classical music that is still under copyright. No sense playing an old mozart recording when you can't run any advertisements for it.

  • foo (unregistered) in reply to Len
    Len:
    foo:
    Len:
    foo:
    Except for the little problem that you often have several files with the same base name (foo.c, foo.h, foo.o, foo or foo.exe; or foo.tex or foo.doc and foo.pdf; etc.). Even if you had a file system that allowed files to share the same name
    If your goal is to group some similar or related files together somehow, you can, you know. They can even share (part of) the same name:

    foo/c, foo/h, foo/o, foo or foo/exe; or foo/tex or foo/doc and foo/pdf

    And this serves to remove the metadata (file type) from the file name exactly how?
    It doesn't. You said you wanted a collection of related files that shared part of their name. You can do that. You don't need a "file type extension" to do that.
    I was replying to Carl who suggested the type "should be a separate attribute in the directory, not part of the name". In which case those related files shared not part, but all of their names, that's what I pointed out.

    Your suggestion is a different way to make the type part of the file name. Basically you replace the dot with a slash, which is more work for the machine (creating more subdirectories, probably irrelevant), may be better or worse for the human (more changing directories vs. less searching in longer file lists), but doesn't do anything WRT what Carl said.

  • Darth Paul (unregistered) in reply to Febreze
    Febreze:
    Calling it:
    The last one seems very fake to me...

    Oh yeah of course it does... Apple never has bugs in their products. They are just features you didn't know you wanted.

    iPhones do disable themselves under some circumstances - for example, if they have not yet been plugged into a computer with iTunes software installed. This is a real WTF on Apples part.

  • Darth Paul (unregistered) in reply to pkmnfrk
    pkmnfrk:
    Tom:
    Kasper:
    press and hold the home key while the phone is connected to a computer or a Mac
    You have an odd conception of "or".
    Kasper:
    ...with iTunes installed.
    Wait, what? You have to have iTunes to manage your iPhone? WTF???

    Um, yes? It lets you backup your phone, install updates, copy files and apps, etc. Or, do you expect Windows to be able to do this by itself?

    Yes. I would rather Apple wrote a plugin for Windows Media Player so I don't have to have more than one installed (or use theirs). Thankfully, someone else already has. And Windows could do all of those tasks (except updates and app installation) from first principles on a properly designed piece of hardware, given the chance. The phone could do the rest by itself. Unnecessary software is unnecessary.

  • Norman Diamond (unregistered) in reply to Carl
    Carl:
    Don't store metadata in the file name. I mean you don't store the last modified date in the file name do you?
    My camera does.

    It took a while to figure that out, too. The filenames are not sensible like yyyymmddzzzz.jpg. They're mddyysomething.jpg. One byte for m because it's a Shift-JIS character representing a hex digit (1 through C).

    I hope they put more competent designers on their medical equipment.

  • Norman Diamond (unregistered) in reply to Steve The Cynic
    Steve The Cynic:
    MindChild:
    Some massivly cruddy code from the 16-bit era used to make the window "invisible" by simply placing it outside your screen real estate.
    That is epically cruddy, as you just need to remove WS_VISIBLE from the style bits...
    Last I saw, if you call a Win32 API to make a window invisible, Windows sets the coordinates to around -3000 or something like that.

    Windows 98 used to be the worst for trying to restore an Internet Explorer window from the task bar and getting a window with negative coordinates and negative size. I think Windows XP did it to me a few times too.

  • (cs) in reply to Darth Paul
    Darth Paul:
    Unnecessary software is unnecessary.

    I took a particular disliking to iTunes when I discovered that not only does it silently install a filesharing program, but it also silently opens said file sharing program up in the Windows Firewall settings...

    Before I found out about that, I was simply annoyed that iTunes had to be on my work PC because it slowed it down so damned much.

  • Kasper (unregistered) in reply to Tom
    Tom:
    Kasper:
    press and hold the home key while the phone is connected to a computer or a Mac
    You have an odd conception of "or".
    No, that really is what the source said. Exact wording from the source:
    Telefonen skal slukkes, og så skal den forbindes til en computer eller Mac, mens man holder homeknappen nede.
    Translated to English by Google translate:
    The phone must be turned off, and then connect it to a PC or Mac while holding down the home button.
    Though Google translate made one mistake by translating computer into PC.
    Tom:
    Wait, what? You have to have iTunes to manage your iPhone? WTF???
    That's what the source said. I wouldn't know, since I never owned an Iphone.
  • snoofle (unregistered)

    This is almost as dumb as I am.

  • (cs)

    I gotta concur here: the problem is not so much the file type being part of the name, as the ability for files with the same name but different types to coexist, in other words for the type to be part of the file identifier, regardless of where the type is actually stored. From the moment MS-DOS, err I mean CP/M (which indeed did store the type in a separate location, AFAIK) had this "feature", it was too late: anything that wanted to be compatible with them, while identifying with only a file name (like, say, file transfer programs, or virtual FAT), had no choice but to integrate the type as being part of the name, using the convention (filename + "." + type) used by these earlier systems for recalling a file as a command parameter when there was a type ambiguity.

    I did some research, and this seems to trace back to early timesharing systems; while I can't find it at the moment, I read a pdf of introduction to the usage of either CTSS or Multics (or maybe some other early TS system) which showed usage of the assembler to transform a program from its assembler "form" to its executable "form", creating a file with the same name but different type, and the two would coexist, this was specifically mentioned as a property of the file system (the document did not use these terms exactly). So it seems to have originated from program building needs, kind of like file.c -> file.s -> file.o which is still used when building programs in many cases.

    So everyone in desktop computing is using filename extensions because Windows dominates so everyone else has to accommodate it, Windows uses them because it has to be compatible with MS-DOS, MS-DOS used (too soon?) them because it strived for compatibility with CP/M, CP/M used them because Gary Kildall wanted as many minicomputer features as he could on his microcomputer, and I don't know precisely why TOPS-10 (which seems to have been the main influence on CP/M) had them, but broadly it was because it was in the air in computing at the time. The fact everyone in the desktop computing world still uses a "solution" even though the problem it solves has become irrelevant 25 years ago for most users, and is today irrelevant for 99.99999% of them (even programmers, given that modern makefiles and IDEs would be able to solve the problem in that case) speaks volumes to power of backwards compatibility of storage (so think twice when you design your database schemas, people!). Apple is attempting to not so much solve the problem, as make it irrelevant in iOS by making the filesystem irrelevant, but I don't think that will work.

    Tomorrow, we will see why the USB mass storage specification is not really an appropriate media synchronization mechanism. I mean, the portable device having to unmount the whole partition and give up access to it so that the desktop OS can access it raw and mount the filesystem itself (so it must be one the desktop OS supports, hello vFAT), the device having no idea what the computer is changing and in particular not being able to check as they are loaded (in other word, at the time the user is interacting) whether media files (like, say, .ogg) are ones it supports, the device having no choice but to fully rescan the filesystem once it regains back control to figure out what changed… what's not to love here?

  • Kasper (unregistered) in reply to ZPedro
    ZPedro:
    Tomorrow, we will see why the USB mass storage specification is not really an appropriate media synchronization mechanism. I mean, the portable device having to unmount the whole partition and give up access to it so that the desktop OS can access it raw and mount the filesystem itself (so it must be one the desktop OS supports, hello vFAT), the device having no idea what the computer is changing and in particular not being able to check as they are loaded (in other word, at the time the user is interacting) whether media files (like, say, .ogg) are ones it supports, the device having no choice but to fully rescan the filesystem once it regains back control to figure out what changed… what's not to love here?
    Not all devices do it that way. I have come across devices, which used their own proprietary protocol to communicate with the computer. That allowed the device to maintain control over the media while the computer could access files on the device.

    But frankly, I'd rather maintain a situation where you cannot have both computer and device access the file system simultaneously, than having to deal with a vendor's proprietary protocols.

    Those are not the only two options. There are a few other ways to handle the data transfer, but I haven't seen any device doing it.

    You could use some standardized protocol working at a higher level than the block device. For example since you can run Ethernet over the cable (possible even if it is a USB cable), then any networking file system could be used.

    Alternatively the device could emulate a FAT file system. The device makes it look to the computer as if there is a FAT file system, and the device seeing every single block being read or written, knows what the computer is doing to the virtual FAT file system, and the device can map back to the underlying file system.

    Any solution involving FAT at any layer is suboptimal from my point of view, but it has proven possible to come up with even worse solutions.

  • foo (unregistered) in reply to Kasper
    Kasper:
    ZPedro:
    Tomorrow, we will see why the USB mass storage specification is not really an appropriate media synchronization mechanism. I mean, the portable device having to unmount the whole partition and give up access to it so that the desktop OS can access it raw and mount the filesystem itself (so it must be one the desktop OS supports, hello vFAT), the device having no idea what the computer is changing and in particular not being able to check as they are loaded (in other word, at the time the user is interacting) whether media files (like, say, .ogg) are ones it supports, the device having no choice but to fully rescan the filesystem once it regains back control to figure out what changed… what's not to love here?
    However note that every device that uses memory cards or other removable media has to do this anyway.
    You could use some standardized protocol working at a higher level than the block device. For example since you can run Ethernet over the cable (possible even if it is a USB cable), then any networking file system could be used.
    Or networking protocol (HTTP, FTP) ...
    Alternatively the device could emulate a FAT file system. The device makes it look to the computer as if there is a FAT file system, and the device seeing every single block being read or written, knows what the computer is doing to the virtual FAT file system, and the device can map back to the underlying file system.

    Any solution involving FAT at any layer is suboptimal from my point of view, but it has proven possible to come up with even worse solutions.

    Also any solution that works backwards (interpreting block access to retrieve the logical file operations) it "suboptimal" from my POV, i.e. only acceptable as a temporary kludge if no short-term alternative exists.

  • alex (unregistered) in reply to Nutster

    It is not a coincidence that that time is also approximately the number of minutes since the Unix epoch.

    iOS is UNIX based. The iPhone's battery must have gotten too low to keep the clock so it reset to Jan 1, 1970.

    To fix this, if the device is jailbroken you can use iFunBox's USB console to log in and use date to change the date until the time you have to wait to unlock the device becomes 0.

    Or if it's not jailbroken and can still connect to WiFi automatically then you might be able to spoof time.apple.com and make the iPhone think you're the time server, change the time as you wish.

  • (cs) in reply to foo

    Ah, found it: http://web.archive.org/web/20110515000340/http://larch-www.lcs.mit.edu:8001/~corbato/sjcc62/ (from http://en.wikipedia.org/wiki/Computer_file). Turns out filename+type (here in fact "title" and "class") is not specifically mentioned as a feature, but is obvious from the command descriptions. So the underlying concept of file extension has been around for at least 50 years now and is apparently as old as named files themselves.

    Please somebody shoot me.

    Kasper:
    Not all devices do it that way. I have come across devices, which used their own proprietary protocol to communicate with the computer. That allowed the device to maintain control over the media while the computer could access files on the device.
    Correct, there are even not-completely-proprietary protocols like Microsoft's MTP to do so. And I indeed wonder why networking/high level file protocols have not been used (or if they were, not significantly) for that purpose as well; maybe complexity of server implementation given the embedded constraints of the time?

    (Tom and the like, on the other hand, implied the iPhone and the like should have specifically used USB mass storage.)

    foo:
    ZPedro:
    Tomorrow, we will see why the USB mass storage specification is not really an appropriate media synchronization mechanism. (…)
    However note that every device that uses memory cards or other removable media has to do this anyway.
    And what does that tell you about devices that use memory cards or other removable media? (setting aside digital cameras/camcorders, where the media transfer is one-way).
  • foo (unregistered) in reply to ZPedro
    ZPedro:
    Ah, found it: http://web.archive.org/web/20110515000340/http://larch-www.lcs.mit.edu:8001/~corbato/sjcc62/ (from http://en.wikipedia.org/wiki/Computer_file). Turns out filename+type (here in fact "title" and "class") is not specifically mentioned as a feature, but is obvious from the command descriptions. So the underlying concept of file extension has been around for at least 50 years now and is apparently as old as named files themselves.

    Please somebody shoot me.

    Not before you've told us your superior solution to the abovementioned problem of several files with the same (base) name. Sure, you could move the type from the name to some other metadata, and have applications automatically set this new metadata, and provide a way for the user to choose between those several files. How is this much better than having applications automatically add the file name extension and provide a way for the user to choose, by picking in the file list which is one subhierarchy less for the user to browse.

    And that's assuming all software, including communication protocols, backup and archival and everything else was suddenly equipped with support for the new scheme, and users would all know how to use it without any extra learning effort. I.e. all backward-compatibility issues aside, I still fail to see its superiority.

    Kasper:
    Not all devices do it that way. I have come across devices, which used their own proprietary protocol to communicate with the computer. That allowed the device to maintain control over the media while the computer could access files on the device.
    Correct, there are even not-completely-proprietary protocols like Microsoft's MTP to do so. And I indeed wonder why networking/high level file protocols have not been used (or if they were, not significantly) for that purpose as well; maybe complexity of server implementation given the embedded constraints of the time?
    Or maybe vendor lock-in? Oh no, you were talking about Apple and Microsoft, can't be ...
    foo:
    ZPedro:
    Tomorrow, we will see why the USB mass storage specification is not really an appropriate media synchronization mechanism. (…)
    However note that every device that uses memory cards or other removable media has to do this anyway.
    And what does that tell you about devices that use memory cards or other removable media? (setting aside digital cameras/camcorders, where the media transfer is one-way).
    I don't know. Maybe that they support the features users want (like being able to transfer data by swapping memory cards) rather than forbidden what doesn't fit into your restrictive software design?
  • ysth (unregistered) in reply to Jeff
    Jeff:
    Dave:
    In Staples, when a product cannot be sold yet, the price in the system is 9999.99.
    No, no, wrong, wrong, WRONG! This is known as attribute overloading. As in, this attribute is the price, except when it isn't.

    Yeah, this is really unbelievable. Don't they know the not for sale price should be -209.90?!

  • ysth (unregistered) in reply to foxyshadis
    foxyshadis:
    Tom:
    But yeah, why would you need a music app to manage your phone?
    Stop being a dick and do some basic research on what you're ignorantly spouting off about.
    I think you are missing the basic point that "iTunes" is completely misnamed for its current functionality. Of course, Tome should cut Apple some slack; once you invest a lot into branding like that, you are stuck, just as Google is stuck with the name Android Market even though they are now selling music and other content, not just apps.
  • (cs) in reply to foo
    foo:
    ZPedro:
    Ah, found it: http://web.archive.org/web/20110515000340/http://larch-www.lcs.mit.edu:8001/~corbato/sjcc62/ (from http://en.wikipedia.org/wiki/Computer_file). Turns out filename+type (here in fact "title" and "class") is not specifically mentioned as a feature, but is obvious from the command descriptions. So the underlying concept of file extension has been around for at least 50 years now and is apparently as old as named files themselves.

    Please somebody shoot me.

    Not before you've told us(…)
    You keep outta this! He doesn't have to shoot you now!

  • corroded (unregistered) in reply to Nutster
    Nutster:
    And it sat at somebody's desk for a week and an IPhone still has 22% charge?! I guess, one, it was not plugged in and, two, it was not looked at during that week, so was in a very-low-power setting.
    after sitting in the Mobility admin's desk for a week he switched it on

    To be fair off is a very low power setting! ;)

  • Peter (unregistered)

    You can get the cd here:

    http://www.amazon.com/Titanic-Other-Scores-James-Horner/dp/B007RF37DI/ref=sr_1_13?ie=UTF8&qid=1355136801&sr=8-13&keywords=James+horner+titanic+movie+scores

    So imho it's not really a WTF.

  • Evan (unregistered) in reply to David
    David:
    The fact that it's on a Beethoven playlist would probably be a WTF as well

    I think pandora intentionally pushes film scores on classical seed stations because its the only thing remotely close to classical music that is still under copyright. No sense playing an old mozart recording when you can't run any advertisements for it.

    You might want to ask for your money back on that law GED.

    The copyright for the music itself is expired, but recordings of classical pieces have their own copyright which is in equal force.

    Peter:
    You can get the cd here:

    http://www.amazon.com/Titanic-Other-Scores-James-Horner/dp/B007RF37DI/ref=sr_1_13?ie=UTF8&qid=1355136801&sr=8-13&keywords=James+horner+titanic+movie+scores

    So imho it's not really a WTF.

    Pandora is still wrong about the album title, though I'm not sure how WTFy that is.

  • Shadyman (unregistered)

    In regards to the Staples "price drop", note the previous price of "$9999". That is the price granted to an item that has a set Release Date / "Street Date".

    The real price is pushed the evening before a release (so that customers and employees can't buy it before release without (A) A lot of money, and (B) Someone noticing that the item is priced ludicrously).

    After the new price is pushed, and any sign referencing savings will inevitably pull the "last price" value of $9999... at least until the price drops (even marginally), such that the "last price" will be something sane.

  • Shadyman (unregistered) in reply to Shadyman

    On second look, they were actually selling off the Demo unit, which is sometimes stored under a different SKU, and would have been $9999 so that no one sold it until it went clearance as it did in the photo.

Leave a comment on “(Situation) (location) has been cleared”

Log In or post as a guest

Replying to comment #:

« Return to Article