Closed lobodpav closed 10 years ago
Interesting - what's your use case for this? I would think using it leaves you open to race conditions.
It leaves you if you use it incorrectly, that is correct. The use case is that in my app, I perform a startup check of availability of essential services and also checking if the log directory (say /var/log/myApp/) is writable to ensure log files can be created and rotated. If the dir is not writable, I prevent the app to start.
But wouldn't attempting to open the log file for writing achieve the same thing?
Nope. The log dir might have read-only permissions while the log file will have write. You start the app, open the log file for writing and it works just fine. However, once you need to rotate the logs, you will fail.
Ah interesting!
I wonder if we can find a Windows API equivalent.
There must be something. But I have never developed in Windows so neither a clue what API there is nor how Windows node addons are built :(
Me either. The way I did it for fs-ext current functions was to look at other languages' implementations of those functions.
I see. Maybe some googling would help. Will try it out if I find a bit of time :)
From some googling, I think it'll compile natively on Windows due to the POSIX layer. Perl's POSIX.xs code has no ifdef code for Win32 around the access() function.
But the FreeBSD man page warns that access() should never be used due to race conditions, so I'd rather not add it to fs-ext (because part of the purpose of writing fs-ext was to mitigate huge security holes in Node code due to lack of file locking), so I'm going to close this issue.
Venturing off-topic, but: As a workaround for the log rotation scenario, you might be able to use some combination of fs.stat() and process.getuid() (or, possibly better, process.geteuid() from node-posix) to simulate the access() check and determine whether or not the log directory is likely to be writable. Another possibility might be to just try to create a file in the target directory at startup, see if it errors out, and then unlink it if the creation was successful.
Well, I have implemented the access() wrapper myself so that I do use my own unix-access module at the time being and it serves its purpose. By this issue I wanted to make it part of fs-ext not to have FS functions crumbled into many modules.
I have created sync/async versions of the UNIX access() function. It may be a good idea to incorporate it into your module not to be available separately as it is now. Check it out here: https://github.com/lobodpav/node-unix-access
What do you think? The only thing is that my module works on UNIX-like systems only.