Re: Programmatically detect removed usb stick?
On Sat, Jun 11, 2011 at 3:47 PM, Benny Lofgren bl-li...@lofgren.biz wrote: On 2011-06-11 10.08, T wrote: I'm writing a small program which changes working dir to a specific directory (using chdir()), and then opens, reads, and closes files in that directory, depending on user actions. Sometimes this directory is located on a mounted USB stick. I'm looking for a simple way to detect, from within my program, if a user have removed the USB stick without first unmounting it. The simplest way, I thought, was to check errno for EIO or ENXIO (depending on whether an error occurs in fread() or fopen()). However, that does not seem to work, because if I call fopen() after the USB stick has been removed, the return value is NULL, and the errno code is ENOENT instead of ENXIO, which sort of makes sense (the file certainly is not there any more), but the cause of the error cannot be differentiated from a regular mis-spelling of the file name. So is there some reliable way of detecting whether the underlying storage device has gone away when a library/system call fails, even if the OS still regards the filesystem as being mounted? Can I, upon detecting errno==ENOENT after fopen(), use some other calls (for example ioctl(), getfsstat(), or statfs()) to determine whether the cause is a mis-spelled filename or removed USB stick? What is the recommended/preferred way? Can/should I perhaps do something before attempting the fopen(), to find out whether the USB stick is still attached? I prefer simple solutions using standard library/system calls, and would like to avoid attaching to some notification mechanism, and tailing the kernel log looking for USB detach messages is a clumsy last chance solution. Try to do an open(., O_RDONLY) if your fopen()/fread() fails. If you get -1 and ENOENT then the file system where you've parked your cwd is no longer mounted (statfs() should also work equally well, but then you'd need to declare a statfs struct you'd have no further use for). It's not wise to check before your fopen():s, because they may still fail if the user pulls the USB stick in the right moment, only use it as a verification of *what* actually went wrong. Thanks for the replies, on- and off-list. I ended up going with Benny's open(., O_RDONLY); suggestion, which felt cleanest, easiest, and had the highest probability of being portable, should the need arise. Works like a charm. Dave
APPELS D'OFFRES PUBLICS
LYMAE FORMATION Inginierie des marchis publics MAITRISER LA PRATIQUE DES MARCHES PUBLICS M O D U L E S D E F O R M A T I O N P O U R E N T R E P R I S E S Module 1: Passation / exicution des marchis - Jeudi 08 septembre 2011 nbs p;nb sp;n bsp; nbsp; Module 2: Dimatirialisation des riponses aux appels d'offres - Vendredi 09 septembre 2011 n bsp; nbsp; ; Madame, Monsieur, Devant les modifications constantes de la riglementation des marchis publics et la montie en puissance de la dimatirialisation des riponses aux appels d'offres, Lymde formation, entreprise spicialisie en inginierie des marchis publics, propose 2 modules de formation destinis aux entreprises souhaitant gagner des parts de marchis dans la sphhre publique: - Module 1: Passation/exicution des marchis: Co nsulter le programme en cliquant ici. - Module 2: Dimatirialisation des riponses aux appels d'offres: consulter le programme en cliquant ici. Ces formations sont organisies avec des mises en situation pratiques (veille de marchis publics, ridaction de mimoire ` candidature, mimoire technique, mimoire de conformiti, DC1 et DC2, positionnement de votre offre, acchs aux plates-formes de dimatirialsiation pour chaque stagiaire, ...) et accompagnies de rappels thioriques (rhgles auxquelles sont soumises les entreprises candidates, comment ripondre au stade de la candidature et de l'offre, les diffirentes formes de procidure de mise en concurrence, les seuils des marchis publics, les relations avec la personne publique pendant une procidure de mise en concurrence, les voies de recours pour contester le rejet de votre offre, dernihres jurisprudences ...). A l'issue de ces modules de formation, chaque stagiaire aura la mantrise de tous les aspects abordis durant la session. Ces modules sont indipendant et peuvent jtre suivis sipariment selon les besoins de chaque participant. Ces sessions sont animies par une iquipe de praticiens juristes et acheteurs publics, chargis de concevoir les dossier d'appels d'offres, analyser les dossiers de riponses et choisir l'offre iconomiquement la plus avantageuse. Nous vous invitons ` prendre connaissance de notre programme en cliquant sur les liens ci-dessous et ` riserver votre place dhs aujourd'hui en raison du nombre limiti de participants (ces journies sont ouvertes exclusivement aux entreprises). Bulletin d'inscription module 1: page 4 du document Bulletin d'inscription module 2: page 3 du document Prix : 470 net / personne / module de 1 jour. Nous pouvons igalement organiser ces modules de formation en intra, au sein de votre entreprise (nous consulter au 01.42.78.30.13 ou 06.12.43.01.77 ou par email: ly...@hotmail.fr) Lymde formation est une entreprise spicialisie dans l'inginierie des marchis et contrats publics; de nombreux professionnels privis et publics dans ce domaine ont binificii et appricii nos formations dans toutes les thimatiques liies aux marchis publics. Pour consulter nos rifirences: cliquez sur le lien rifirences. Nous mettons notre expirience au service des entreprises souhaitant s'initier ou se perfectionner dans le domaine des riponses aux appels d'offres publics. Nos actions couvrent igalement d'autres modules de formation au service des entreprises. Pour consulter l'ensemble de nos formations: cliquez sur le lien for mations. Dans l'attente de vous rencontrer, nous vous prions d'agrier, Madame, Monsieur, nos respectueuses salutations. Lymde formation/conseils Inginierie des marchis publics - 13 rue Geoffroy L'Angevin 75004 Paris Siret: 5045520516 - N0 diclaration d'activiti: 11 75 43426 75 Tel/Fax: 01.42.78.30.13 - Portable: 06.12.43.01.77 Email: ly...@hotmail.fr Ce message n'est pas un SPAM, car il contient nos donnies d'identification et les instructions pour se disabonner. Ce message vous a iti envoyi pour les raisons suivantes : vous jtes un partenaire de notre entreprise, vous jtes dans notre base de donnies en raison d'une pricidente correspondance, votre adresse a iti silectionnie ` partir d'une base de donnies dans laquelle vous jtes rifirenci, votre adresse a iti rendue publique par vous. Si vous ne souhaitez pas recevoir nos offres ou si ce message vous a iti envoyi par erreur, veuillez cliquer sur le lien de disabonnement ci-dessous pour retirer votre adresse e-mail de notre liste de diffusion. Disabonnement liste de diffusion
different nwkeys for wifi
Scenario: I am moving my laptop between different wifi networks (obviously). Some of these networks are encrypted with WEP, using various nwkeys. What would be an elegant way to remember the various networks' settings and choose the one I am connecting to at netstart(8) time? Before I start symlinking /etc/rc/hostname.run0.whatever in my rc.local, what existing solutions do people use? Thank yuo for your time Jan
Re: different nwkeys for wifi
I use a simple AWK script which parses the available networks as
returned by ifconfig wpi0 scan and selects the first known one it finds.
It then creates an /etc/hostname.wpi0 for that network and runs
/etc/netstart wpi0. I attached it for reference, though I think it's
extremely easy to rebuild from scratch.
--
Gregor Best
#!/usr/bin/awk -f
BEGIN {
conf[essid0] = wpakey foobar\ndhcp;
conf[essid1] = -wpakey\ndhcp;
device = wpi0;
}
/^[[:space:]]+nwid/ {
sub(^[[:space:]]+nwid , )
sub( chan [[:digit:]]+ bssid.+, )
if ($0 in conf) {
print Using configuration for ESSID $0
print up\nnwid $0\nconf[$0] (/etc/hostname.device)
system(sh /etc/netstart device)
exit
}
}
pgpR0l9QtVop0.pgp
Description: PGP signature
Re: different nwkeys for wifi
Scenario: I am moving my laptop between different wifi networks (obviously). Some of these networks are encrypted with WEP, using various nwkeys. What would be an elegant way to remember the various networks' settings and choose the one I am connecting to at netstart(8) time? Before I start symlinking /etc/rc/hostname.run0.whatever in my rc.local, what existing solutions do people use? tedu@ posted a perl script on misc@ about a year or so ago. HTH
Re: different nwkeys for wifi
I use the following perl script below. I saved it in /etc/rc.wireless
and apply the following patch:
--- netstartFri Jul 8 15:34:09 2011
+++ /etc/netstart Sun Jul 10 11:43:20 2011
@@ -255,6 +255,8 @@
ip6kernel=NO
fi
+#wifi
+/etc/rc.wireless
# Configure all the non-loopback interfaces which we know about, but
# do not start interfaces which must be delayed. Refer to hostname.if(5)
Good luck!
Luis.
#!/usr/bin/perl -w
# TODO
# 1. Connect to ethernet if available instead.
# 2. Retry if the network was not found.
use strict;
my $nwif = iwn0;
my $profiles = {
wpanet = {psk = passwordwpa, proto = wpa },
noencrypt = {},
wepnet = {psk =passwordwep, proto = wep},
};
sub conf_nw {
my $nwid = shift;
my $conf = $profiles-{$nwid};
my $psk_str = $conf-{psk};
if($psk_str) {
my $proto = lc $conf-{proto};
if($proto eq wep) {
$psk_str = nwkey \$psk_str\;
} elsif($proto eq wpa) {
$psk_str = wpakey \$psk_str\;
} else {
die Only \wep\ and \wpa\ supported.;
}
} else {
$psk_str = -wpakey -nwkey;
}
# finally write in hostname.if
open HOSTNAME, /etc/hostname.$nwif or die Couldn't open hostname.if
file.;
print HOSTNAME # THIS IS A TEMPORAL FILE.\n# MAKE THE MODIFICATION
IN /etc/rc.wireless.\n;
print HOSTNAME dhcp nwid \$nwid\ $psk_str\n;
close HOSTNAME;
}
print Configuring wifi $nwif... ;
my $nwid = no known net;
# scanning available networks
open FD, ifconfig $nwif scan| or die where'd ifconfig go?;
while(FD) {
if(/^\s*nwid ?(.*?)? chan/) {
if($profiles-{$1}) {
conf_nw $1;
$nwid = $1;
last;
}
}
}
print $nwid detected\n;
On Sun, Jul 10, 2011 at 12:51 PM, Jan Stary h...@stare.cz wrote:
Scenario: I am moving my laptop between different wifi networks
(obviously). Some of these networks are encrypted with WEP, using
various nwkeys.
What would be an elegant way to remember the various networks' settings
and choose the one I am connecting to at netstart(8) time? Before I start
symlinking /etc/rc/hostname.run0.whatever in my rc.local, what existing
solutions do people use?
Thank yuo for your time
Jan
Re: How does OpenBSD compare to Ubuntu Server?
STeve Andre' [and...@msu.edu] wrote: On 07/07/11 15:12, Amit Kulkarni wrote: The developers don't adopt new things just because they're new. If something isn't reasonable, useful and secure it isn't used. This is one reason why each new release of OpenBSD doesn't have the currently released version of gcc, for example. Wrong. It is because of GPL v3. Gcc in base won't be updated AFAIK. No, this has always been the case. I remember back around 2.5 or so, seeing that OpenBSD hadn't upgraded to the latest gcc, wondering why. The GPL 3 issue of today is relevant, but it extends beyond that. For GCC after 4.2.1, the license is the problem. That is why OpenBSD has 4.2.1+fixes instead of something newer import of gcc-4.2.1, the last gcc release under GPLv2. Same thing is happening right now with binutils 2.17. When OpenBSD went to 2.95.3, to 3.3.5, and again to 4.2.1, the problem each time was the amount of effort required to make it work. When the behavior in GCC changes, or when you run into new compiler bugs, it's a time-consuming problem that disrupt work going on in the system. With the 4.2.1 upgrade, problems with GCC store re-ordering optimization extended into 4.8 release, affecting critical areas like bus_dmamap_sync(). Of course the bulk of the compiler upgrade problems were solved before 4.8. (Solved because people took time to track down, identify and fix those problems.) It's a pain in the ass to swich compilers. It ends up forcing people to troubleshoot code that isn't broken, slowing down other work until the actual compiler problem is identified and workaround applied. OpenBSD historically didn't upgrade compilers until the pain of sticking with the existing compiler met or exceeded the pain of upgrading the compiler. There were plenty of reasons to look at GCC 4 in base for several years now, but the increase in compile time (each generation of GCC is slower than the last) made a switch to GCC 4 less attractive. No consensus to move to GCC 4 was possible. What finally pushed GCC 3.3.5 over the edge was the broken C++ compiler (also not ABI compatible with G++ 4, so everything that linked to a G++ 4 program had to also be compiled with G++ 4. But people want their complex C++ ports to work) Four or five years from now when GCC 4.2.1+fixes becomes too painful, OpenBSD may adopt something new, who knows, maybe llvm or pcc will support more architectures by then? Maybe the GPL 3 will become OK? GCC 4.2.1 is working pretty damn well now.
