Windows .LNK format? OH MY GOD.

Is this f*cking necessary, people? I went to add support for windows shortcuts into jEmplode ... The spec is _12 pages long_. This is officially the most overdesigned spec ever.

That is all.

ms

The IE .URL file specification is pretty long and that's just a text file....

Especially when you consider that NTFS has native support for hard links that would be totally transparent.

NTFS has native support for hard links

Yeah, but:

1. There's no user-level API for creating them in anything older than Windows XP.
2. They're not available on FAT32, which quite a lot of people still use.
3. We really want soft links.

If we're talking about NTFS features, then there's always reparse points, which are like symlinks on steroids.

Which spec? All I could find was this, which is only 3 pages.

I'll track down the link -- it was a PDF format .. clearly more verbose than the link you have. Even the distilled view is a lot of information for a /link/, though.

So w/ the Win32 API's, are these transparent to you? That is, if you encounter a .lnk in a list of files, if you open a stream to that, will it act like a symlink?

ms

if you open a stream to that, will it act like a symlink?

No, but there is a set of COM interfaces for resolving the link to its target, which makes it a lot simpler.

This is officially the most overdesigned spec ever.

IMAP4rev1?

Peter

In reply to:

---

IMAP4rev1?

---

touché

Dunno. I vote for NFSv4 I've had the misfortune to have to implement it.

I still disagree that IMAP is overengineered. Pretty much every piece of it fits an action a mail user might want to take. That may be a lot of things, but when it fits, I can't see calling it overengineered.

I see your point about the fact that it has most, if not all, of the features of a remote filesystem, but that doesn't mean that it's too big, just that the problem was large.

i feel bad. i was the one who requested it. also the one who gave you the link to that pdf. probably the only person in here that would actually make use of it. tell you what. if its too much, then forget it.

but here's an interesting link

newsgroups are awesome.

This link absolves you from all guilt. I must say, I was going down the "purist" route rather than the brute force route -- that is, I was actually parsing all of the fields of the format. This guy took the "just skip over stuff i don't care about" approach, which is certainly a better way of getting it done.

hey, by all means, fill in the blanks if you feel the conviction to do so. just browsing the code, i don't see it being able to map a network drive if its not connected. always found that a fun property of windows shortcuts. first time i encountered it, i was trying to troubleshoot why someone's login script wasnt mapping drives. she tells me that all she has to do is dblclcik the shortcut to a file on the drive that she created on her desktop, and then her F: drive appears after. i was like... cool. so taking the easy way out, i made a blank batch file, put it on the network drive, made a shortcut to it, and put it in startup.

We had the same problem getting an implementation for OpenAFS. Until just recently nothing worked, and we haven't done a release that does, yet.

I thought ACAP was worse.

I'm playing with MAPI this afternoon, and that's fairly out of control.

Conceptually, it's all quite sane, but there's a whole bag of other stuff you need to worry about, like the slightly bizarre memory allocation semantics, and the fact that it was designed in the early days of COM, before anyone knew what they were doing.

I thought ACAP was worse.

Oh look, it's a remote filesystem.

Peter

Oh look, it's a remote filesystem.

In fact, yes. I was actually at the charter meeting where the ACAP spec got off the ground. It was trying to solve too many problems, and not surprisingly it died.

Unfortunately people now use LDAP for the stuff it was intended to do. LDAP isn't exactly an example of a simple protocol, either, and my opinion is it's less clean than ACAP was going to be.