Hacker News Reader

Comment by chancho | Hacker News Reader

Can someone with knowledge of the underlying OS mechanisms answer this for me: What is the deal with file access on Windows? In Linux (on the Mac too, I think) I can move, copy and delete files freely, regardless of what applications currently have that file open. On Windows, I always run into some situation where it won't let me do what I want to do because the file is open. So I have to hunt through 10-20 windows to see who has it (9 times out of 10 its a command prompt or explorer window holding on to a directory that I'm trying to delete.)

I don't use windows often so maybe I'm exaggerating, but this is the single most infuriating windows usability nitpick I have. Have they fixed this in Vista or 7?

View on HN

This happens because of underlying implementation of file systems. UNIX-based systems have the notion of "linking/unlinking" files: a file is a link to a set of sectors on your hard drive. One can create many more links to the same data (using ln command). Deleting is the same as unlinking, i.e. removing a link. When the last link disappears, the file is considered "deleted". When an application opens a file, it creates yet another link to it, so nothing stops you from removing the link - the file isn't deleted yet since your app still uses its own.

I'm not sure how Windows can be "fixed" in this regard, since their filesystems don't have the notion of hard linking nor does Win32 API: there is no way you can move/delete file on Win32 while keeping existing open file handles alive.

However, the biggest issue with Windows, in my opinion, is Registry. Nearly all "popular" Windows gripes can be tracked down to registry abuse: decreasing performance over time, adware/spyware, viruses, etc... Registry is like a secondary file system, but much slower, more primitive, less secure and, most importantly, nearly completely hidden from the users: there are no tools with exception of primitive regedit, to deal with it.

Honestly, the registry is no worse from an end-user POV than the /etc filesystem under Linux. In point of fact, given the diversity of file formats and sources in /etc, it's probably fair to say that the registry is equally navigable and understandable to the average Windows power user as the config tree is to a Linux fan. Because keys are typed and support ACLs, it's also arguably better-protected against accidental or intentional breakage.

If you want to attack an ad-hoc config system, then perhaps talk about the mess that is OS X 'defaults', or GConf's half-assed reimplementation of the Windows registry for GNOME.

That being said, I am most certainly not a Windows partisan. The last time I worked primarily on a Windows system was when I worked for a large hardware manufacturer, and the entire company ran on Exchange + Office. That was over five years ago, and I have been almost 100% on Mac OS X + Linux in the meantime, with only occasional use of Windows in a VM to verify IE compatibility.

The reason is this: for the tools I need to be productive (Vim, Ruby, Java, Firefox, MySQL, IM client, email client) Windows is at best equally capable, and at worst a second-class host, to Linux. OS X is about as suitable a platform for those tools, but has a much smoother media (esp. online video) and mobile story. Hence, the advantages of Windows (huge application library, obscure HW compat) are largely moot, while its disadvantages (poor POSIX/UNIX compat., weird dev tools, cost) are more apparent.

In my Linux days I'd just make a copy of /etc and my home directory and that was always enough to get a new machine, install Debian, run a few aptitude commands, restore /etc and move on.

Try doing it on Windows. There is always a small army of GUI tools, often from 3rd parties, to help you accomplish things like these. Just recently I had to get rid of Adobe CS3 on my Mac: it was easy enough - just run find | grep on your / and you're in good shape. On Windows, big part of the game is played in the registry, and good luck cleaning it up from something as massive and badly written as Adobe software.

Ask an average Microsoft SQL Server user: "WHAT IS MS SQL SERVER?" I mean in terms of files and configuration data that you're putting on your machine when you're installing one. I bet very few people know precisely what it is. MS SQL, just like any piece of reasonably big Windows software, is a complex mesh of files scattered all over your hard drive, hooked up together with a few hundred registry entries scattered all over your registry, and replicating your SQL configuration on another machine is pretty much impossible without yet another complex Windows GUI tool. Internet Explorer is also like that: there are all sorts of hooks and back doors in the registry that you can stick your DLL into, to be loaded and considered a part of MSIE the browser, so an average user, without additional GUI guidance, has no chance of figuring out where all these popups are coming from, hence the need (and a big market) of various spyware/adware removal tools. On Linux/Mac these tools make no sense: a 10 line bash script would accomplish all they do. The reason? It's the registry, the biggest engineering fuck up in the history of Windows.

This is why I hate seeing Gnome moving in that direction - their Gnome Conf is a reincarnation of the same "wonderful" idea: to badly re-implement a file system in sake of elusive "centralized configuration storage" advantage. There isn't any advantage in centralizing your config in some non-standard complex format: you aren't gaining anything, you're loosing a huge army of tools and techniques and people's knowledge which standard file systems come with: just use them, store you config files as files in a file system, it's freaking great at storing files.

> In my Linux days I'd just make a copy of /etc and my home directory and that was always enough to get a new machine, install Debian, run a few aptitude commands, restore /etc and move on.

Even better: go make a VCS-repo for your /etc. It's absolutely great.

I have /etc in a git repo, and an hourly cron job to commit whatever there is to be committed (I should probably use icrod instead of cron, but right now, I'm too lazy.) That way you can fix mistakes that got introduced sometime in the past, and you can see the diffs between different versions of your configuration. Of course, it has the same benefit of being able to just clone the configuration on another machine. EXCEPT, you also get to set up different branches for different hosts, if you need that, but that might be overdoing it already.

Seriously, try keeping more stuff under VCS. I use it for my ~/, my most important dotfiles, and /etc. Great thing.

The main reason I hate the registry and much prefer /etc is that I can do `tar -czf backup.tar.gz /etc/*` and have a backup. I can also fix my machine if things are so bad I have to boot into single user mode. Scripts can easily look at system settings. On the plus side, the registry is more consistent; you don't have to figure out each program's config language.

I think you can export pieces of the registry, and if Windows had better command line tools, scripts could easily look at settings. But as it is now, it's a lot easier to backup and restore /etc than the registry.

backup the registry

regedit /e file.reg

restore the registry

regedit /c file.reg

The Windows registry also keeps the equivalent of many of the "dotfiles" in each user's home directory.

In a binary blob that can't be easily accessed without the system being booted up... at least not that I know of.

Windows has had hard links for a decade or so. Vista even ships with "mklink" which can make three different kinds of links. Before that, you could download utilities to make them. Windows won't unlink a link that is in use because its normal filesystem API promises that behavior. You can use different APIs to get different behavior.

The registry exists in the format it is in to boost performance, not hinder performance. It supports approximately the same ACLs as the filesystem so there is nothing that makes it inherently less secure than the filesystem. And, the registry is designed to be exposed by custom GUIs, not by regedit. For example, to change the registry setting for the default program to open ".html" files with, you could* use regedit, but the Windows philosphy says there should be a dedicated UI for it instead (the "Default Programs" UI in this case).

'Strue. I do get frustrated with the registry model, although I've gotten good at dealing with it. On the other hand, custom GUIs help to improve Linux penetration, since many people are intimidated the command line or configuration file editing.

I like Win and Linux, Mac seems to me to combine the worst of both. Sure, it's personal. Application compatibility matters, Linux lags badly on video & audio editing tools.

When I first ran Linux around 1993, what really annoyed me were Emacs & vi. Sure, they're powerful, but extremely alienating to new users. DOS had Edit, or Windows 3 had Notepad. Ubuntu and like distros succeed because most people just want to drive without learning how to be a mechanic. Linux's biggest problem is people's perception that there's no 'standard' distribution and that they're going to have do an awful lot of icky maintenance.

I don't know whether or not it's fixed in more recent versions, but there are programs which get around this for you (by killing processes, or telling you which process is using the file/folder). E.g. Unlocker http://ccollomb.free.fr/unlocker/

It's fixed in Windows 7 by telling you which application is using the file (http://lifehacker.com/5132227/windows-7-tells-you-why-you-ca...).

For anyone being annoyed by this in earlier versions Process Explorer http://technet.microsoft.com/en-us/sysinternals/bb896653.asp... allows you to quickly search for handles and identify the offending process.

Can someone with knowledge of the underlying OS mechanisms answer this for me: What is the deal with file access on Windows?

The Windows locking defaults when opening file-handles actually includes locking and has done so for such a long time that applications have come to depend on it.

If you check the Win32 API you will see applications have several options for requesting (or not requesting) file-locks when doing file-operations, but not using them, the defaults are to play it safe and ensure that no data is lost due to improper access.

Technologically speaking, this is kinda the same as you have in Linux, except that the defaults are the polar opposite.

Changing the defaults now would break havoc among multiple applications relying on the defaults and cause massive amounts of corrupted data. So Microsoft have kept them as is.

IOW: If you are having issues with file-locking, you need to blame the application-developer for not properly signalling what level and type of locking is actually required, because Windows will respect the locks set on file-handles. Maybe I'm the exception, but I consider that a good thing.

Reply on news.ycombinator.com