Add support for Windows

[maurizi]

[carllerche]

Windows support would be nice. Unfortunately, I don't have time to work on this. I would accept a PR though.

[maurizi]

I did a little bit of research into this.

It seems like Windows could mostly rely on the POSIX implementation. It has a stat function, which handles every nix.rs is being used for now I think...

The big problems I've come across are that:

1. pidfile-rust/src/file_posix.rs

   Lines 99 to 113 in 8a26164

   	pub fn check(&mut self) -> io::Result<pid_t> {
   	let mut fl: flock = unsafe { mem::zeroed() };
   	fl.l_type = F_WRLCK;
   	fl.l_whence = SEEK_SET as c_short;
   	check!(libc::fcntl(self.fd, F_GETLK, &fl as *const flock));
   	if fl.l_type == F_UNLCK {
   	Ok(0)
   	}
   	else {
   	Ok(fl.l_pid)
   	}
   	}

   is trying to get the PID of the process currently holding the lock to the pidfile, which Windows does not seem to support: http://stackoverflow.com/questions/17720315/interogate-which-process-has-locked-a-file-in-windows-c
2. The call to stat here:

   pidfile-rust/src/lib.rs

   Lines 146 to 150 in 8a26164

   	if current_stat.st_ino == path_stat.st_ino {
   	Ok(())
   	} else {
   	Err(self.read_pid())
   	}

   here is using the value of st_ino, but that won't be set for FAT oor NTFS filesystems (this likely applies to those filesystems on linux too!).

@carllerche I'd be curious for your thoughts.

[carllerche]

My knowledge of windows programming is weak. Windows doesn't even have the concept of a PID, so what would the function return?

The goal of the function that you linked in point #2 is to handle the case where the lockfile is deleted external to the process. For example, a user comes around and rm /var/run/*, then the lock should not count anymore.

I think a better strategy for windows would be to figure out what exactly is needed. I originally just figured that the pidfile concept was just a *nix thing. I am not exactly sure what the requirements on windows would be.

[retep998]

What are you talking about? Every process on windows has a process id.

[maurizi]

@retep998 is right, processes on Windows have PIDs: https://msdn.microsoft.com/en-us/library/t2y34y40.aspx.

If the goal of checking the inode with stat is just to see if the file was deleted (and then possibly recreated), would it be sufficient to just read it again and see if the PID matches?

It might be a good idea to switch to that even for Linux systems, since the pidfile could be on a FAT filesystem, which is fairly common for things like external hard drives.

I'm still not sure what the solution would be to my first point though.

[retep998]

At least use the Win32 function for it, and not the CRT one. GetCurrentProcessId.

[carllerche]

@retep998 heh, I did start out with a disclaimer. I Probably should have phrased it as a question.

Regarding point 1, is there a way to see if the file is locked without getting the associated PID? If there is no way to check for a file lock, that is pretty unfortunate. Worst case scenario, I guess the check function could be moved to an Ext trait (similar to std::os::unix stuff)

@maurizi's suggestion to read the pid file seems good.

[maurizi]

I think you can see if the file is locked by attempting to lock it yourself, and seeing if you get an error.

[maurizi]

@retep998 Out of curiosity, why do you suggest prefering using Win32 functions instead of CRT ones?

The CRT ones have the benefit of already being set by libc, so using that should work without changing any of the code for getting PIDs.

[retep998]

The CRT is an additional layer on top of Win32, so it's generally less flexible and has more overhead. I typically try to avoid the CRT as a matter of principle.

[carllerche]

There are bindings to the windows API here: https://github.com/retep998/winapi-rs