Tr: accès aux diques externe interdit
Message du : 13/12/2009 De : dominique.bouche...@sfr.fr A : asus bug Copie à : Sujet : accès aux diques externe interdit Bonjour, Mon Asus Eepc 701sous Linux refuse l'accès aux clés USB, disques externes et sandisk car j'ai perdu le répertoire Media. Comment le rétablir ? Merci de votre réponse à dominique.bouche...@sfr.fr Cordialement D.Boucherie
Re: touch
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[please keep the list in the loop]
According to ctrn3e8 on 12/20/2009 10:04 PM:
touch -m no longer seems to modify the file modification date.
Archlinux,
coreutils-8.2 (package coreutils-8.2-1-i686). Works if use
coreutils-7.6.
What kernel version on which architecture (uname -a)? Can you send an
strace? We recently fixed a bug with kernel 2.6.32 failing to change
ctime when you use 'touch -a'; I wonder if there is another kernel bug we
need to be aware of.
Thanks for responding:
uname:
Linux scitrin 2.6.31-ARCH #1 SMP PREEMPT Tue Nov 10 19:48:17 CET 2009
i686 AMD Athlon(tm) 64 X2 Dual Core Processor 3600+ AuthenticAMD GNU/Linux
Again should not matter.(modifying a file with a modify date from
months ago)...but hardware clock is set to UCT and time then adjusted by
operating system to local time zone
Permissions on the file I chose to modify are okay.
strace output::
...
open(startTimidity, O_WRONLY|O_CREAT|O_NOCTTY|O_NONBLOCK|O_LARGEFILE,
0666) = 6
dup2(6, 0) = 0
close(6)= 0
utimensat(0, NULL, {UTIME_OMIT, UTIME_NOW}, 0) = 0
That works on the Linux kernels that I have attempted. I'm wondering
what's not happening for you?
close(0)= 0
close(1)= 0
close(2)= 0
exit_group(0) = ?
Can you also show 'stat startTimidity' before and after the failing
attempt at 'touch -m startTimidity'?
Also, if you built coreutils from source, running 'make -C gnulib-tests
check' would be informative.
- --
Don't work too hard, make some time for fun as well!
Eric Blake e...@byu.net
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAksvcDAACgkQ84KuGfSFAYDFWQCgijnqf8r3sUAJQMAfAyc+obYC
9YUAn0bGOMpJODJV9Def2bHfxGE/S6Cy
=NEjd
-END PGP SIGNATURE-
Re: Tr: accès aux diques externe interdit
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to dominique.bouche...@sfr.fr on 12/21/2009 12:59 AM: Bonjour, Mon Asus Eepc 701sous Linux refuse l'accès aux clés USB, disques externes et sandisk car j'ai perdu le répertoire Media. Comment le rétablir ? Pardon the fact that I'm replying in English; I am not good at French. You have reached the GNU Coreutils mailing list. The GNU Coreutils are the basic file, shell and text manipulation utilities of the GNU Operating System. You can learn more about GNU Coreutils here: http://www.gnu.org/software/coreutils/ The GNU Coreutils are part of the GNU Operating System. You can learn more about the GNU Project here: http://www.gnu.org/ But you are asking about USB. I am sorry but this is the wrong mailing list. We don't know anything about that here. We are unable to help you here. You may have better luck seeking out a local Linux users group that speaks your language and can help you find answers to your question. - -- Don't work too hard, make some time for fun as well! Eric Blake e...@byu.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAksvcjwACgkQ84KuGfSFAYBnXQCeIM3igzWdoSogb1C3soUzyqjw bYAAoIvv1Rk1TAjMzvdzRBWRbhPlK64x =kSsI -END PGP SIGNATURE-
[PATCH] stat: add support for more file system types
*src/stat.c (human_fstype): Add the following FS types: fuseblk, rpc_pipefs. Also fix a typo of minux3 to minix3 and add ext4 to the ext2/ext3 name. Also mention the fs-magic-compare make target to help update the list. * NEWS: Mention the fix. From f3953d89bfdeb0d875a9d8347723648a593888f0 Mon Sep 17 00:00:00 2001 From: =?utf-8?q?P=C3=A1draig=20Brady?= p...@draigbrady.com Date: Mon, 21 Dec 2009 14:55:17 + Subject: [PATCH] stat: add support for more file system types *src/stat.c (human_fstype): Add the following FS types: fuseblk, rpc_pipefs. Also fix a typo of minux3 to minix3 and add ext4 to the ext2/ext3 name. Also mention the fs-magic-compare make target to help update the list. * NEWS: Mention the fix. --- NEWS |3 +++ src/stat.c | 13 + 2 files changed, 12 insertions(+), 4 deletions(-) diff --git a/NEWS b/NEWS index 6d71e0f..5791e2e 100644 --- a/NEWS +++ b/NEWS @@ -9,6 +9,9 @@ GNU coreutils NEWS-*- outline -*- a commmand of the above form would fail for all subdirectories. [bug introduced in coreutils-8.0] + stat -f recognizes more file system types: fuseblk, rpc_pipefs. + Also minux3 is renamed to minix3 and ext4 is added to the ext2/ext3 name. + tail -f (inotify-enabled) once again works with remote files. The use of inotify with remote files meant that any changes to those files that was not done from the local system would go unnoticed. diff --git a/src/stat.c b/src/stat.c index 2d4a956..67b9068 100644 --- a/src/stat.c +++ b/src/stat.c @@ -208,7 +208,8 @@ human_fstype (STRUCT_STATVFS const *statfsbuf) diff -u sym_stat sym_libc */ - /* Also sync from the list in man 2 statfs. */ + /* Also compare with the list in man 2 statfs using the + fs-magic-compare make target. */ /* IMPORTANT NOTE: Each of the following `case S_MAGIC_...:' statements must be followed by a hexadecimal constant in @@ -256,11 +257,13 @@ human_fstype (STRUCT_STATVFS const *statfsbuf) case S_MAGIC_EXT: /* 0x137D */ return ext; case S_MAGIC_EXT2: /* 0xEF53 */ - return ext2/ext3; + return ext2/ext3/ext4; case S_MAGIC_EXT2_OLD: /* 0xEF51 */ return ext2; case S_MAGIC_FAT: /* 0x4006 */ return fat; +case S_MAGIC_FUSEBLK: /* 0x65735546 */ + return fuseblk; case S_MAGIC_FUSECTL: /* 0x65735543 */ return fusectl; case S_MAGIC_FUTEXFS: /* 0x0BAD1DEA */ @@ -296,7 +299,7 @@ human_fstype (STRUCT_STATVFS const *statfsbuf) case S_MAGIC_MINIX_V2_30: /* 0x2478 */ return minix v2 (30 char.); case S_MAGIC_MINIX_V3: /* 0x4D5A */ - return minux3; + return minix3; case S_MAGIC_MSDOS: /* 0x4D44 */ return msdos; case S_MAGIC_NCP: /* 0x564C */ @@ -321,6 +324,8 @@ human_fstype (STRUCT_STATVFS const *statfsbuf) return reiserfs; case S_MAGIC_ROMFS: /* 0x7275 */ return romfs; +case S_MAGIC_RPC_PIPEFS: /* 0x67596969 */ + return rpc_pipefs; case S_MAGIC_SECURITYFS: /* 0x73636673 */ return securityfs; case S_MAGIC_SELINUX: /* 0xF97CFF8C */ @@ -406,7 +411,7 @@ human_fstype (STRUCT_STATVFS const *statfsbuf) case FSTYPE_MISC: return misc; case FSTYPE_EXT2FS: - return ext2/ext3; + return ext2/ext3/ext4; case FSTYPE_HTTP: return http; case FSTYPE_MEMFS: -- 1.6.2.5
Re: btwowc(EOF) hang with gcc 4.4.2
It's definitely a compiler problem. That extern inline asm alias trickery The gcc people say that the behavior is correct; not a bug. (I don't understand all of their replies, but the conclusion seems clear.) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42440 I don't know if there is a way to change the configure test so it is robust against this particular problem. k
Re: btwowc(EOF) hang with gcc 4.4.2
Karl Berry writes: It's definitely a compiler problem. That extern inline asm alias trickery The gcc people say that the behavior is correct; not a bug. (I don't understand all of their replies, but the conclusion seems clear.) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42440 OK, I understood the replies so I'll try to sum up: The oxymoron extern inline used to have one interpretation before the inline keyword was standardized in C99. In that standardization, a different interpretation for extern inline was mandated. The inline/alias trick used by glibc here needs the old interpretation, which should be requested with the gnu_inline attribute. Your version of glibc doesn't specify gnu_inline. So the problem boils down to: your gcc is too new for your glibc. Downgrade one or upgrade the other.
Re: btwowc(EOF) hang with gcc 4.4.2
Hi Alan, Thanks for the explanation. So the problem boils down to: your gcc is too new for your glibc. Downgrade one or upgrade the other. Ok, that was more or less what I understood also. But it is very depressing. It means it is no longer possible to install the current gcc from sources and use it reliably, independently of whatever gcc the system provides (usually much older, with plenty of different bugs introduced, etc.), something which has always worked before for me since day one of gcc. (In my experience it's never been possible to install the current glibc from sources and have it actually work, so that's not an option.) A big step backwards in my view. All because of optimization to the nth degree of one tiny fn that is useless in all my (and my users') life anyway. Sigh. Oh well, life goes on. Thanks again, Karl
Re: touch
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to ctrn3e8 on 12/21/2009 9:07 PM:
On 12/21/2009 05:55 AM, Eric Blake wrote:
[please keep the list in the loop]
I repeat this plea. Don't send to just me - there are others trying to
follow this discussion.
Okay, it is starting to get wierd. I should have known. Programmers
hate to test, but they do at least do a sanity check and you would have
to assume whoever changed things at least made sure the thing basically
worked before checking it in. Here is where you might start rolling
your eyes with a little with disbelief, but I still think there is
something here...(keep reading to the end!). Yesterday touch -m (using
the 8.2 version) did not work on my home(~) ext4 volume. It now
works on my ext4 volume. What changed I do not now. However, it
continues not to work on my ntfs-3g volume. The ouput (ntfs-3g case) is
provided below. So the question is, what did I change on the ext4
volume?. The answer is, I haven't a clue. I did keep moving back and
forth between coreutils 8.2 and coretutils 7.6. Rebooting is not an
issue...I did try rebooting numerous times with the buggy behavior still
evident. Both volumes are on the same hard disk and I suppose there
could be a hardware issue...but the 7.6 version always works
consistently while the 8.2 seems to be hit or miss.
See also this post on lkml: http://lkml.org/lkml/2009/12/21/118
In other words, it is very likely that there are fs-specific bugs in
utimensat, and the kernel folks are working on the issue. Are you
comfortable joining in on that thread, to provide your observations, since
your report of ntfs-3g is a new instance of a bug report?
But one thing is for certain - the bug is ONLY triggered when using
UTIME_OMIT/UTIME_NOW; it is not triggered when explicit times are
requested. Coreutils 7.6 always requested specific times, we didn't start
using UTIME_OMIT until 8.1. So you won't see the problem with 7.6; and on
8.1 or newer, whether you see the bug will depend on whether the kernel is
buggy for your particular fs.
Anyway the shell ouput for doing it on the ntfs-3g volume follows:
scit...@scitrin:~/P_Drive/testTouch$ stat file1
File: `file1'
Size: 0 Blocks: 0 IO Block: 4096 regular
empty file
Device: 809h/2057d Inode: 6239Links:
1
Access: (0777/-rwxrwxrwx) Uid: (0/root) Gid: (0/
root)
Access: 2009-12-21 20:25:48.0
-0700
Modify: 2009-12-21 20:25:48.0
-0700
Change: 2009-12-21 20:28:38.0
-0700
scit...@scitrin:~/P_Drive/testTouch$ strace touch -m
file1
execve(/bin/touch, [touch, -m, file1], [/* 57 vars */]) =
0
brk(0) =
0x9cf2000
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0xb788a000
access(/etc/ld.so.preload, R_OK) = -1 ENOENT (No such file or
directory)
open(/etc/ld.so.cache, O_RDONLY) =
6
fstat64(6, {st_mode=S_IFREG|0644, st_size=195491, ...}) =
0
mmap2(NULL, 195491, PROT_READ, MAP_PRIVATE, 6, 0) =
0xb785a000
close(6)=
0
open(/lib/librt.so.1, O_RDONLY) =
6
read(6,
\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\220\30\0\0004\0\0\0...,
512) = 512
fstat64(6, {st_mode=S_IFREG|0755, st_size=38520, ...}) =
0
mmap2(NULL, 33364, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 6, 0)
= 0xb7851000
mmap2(0xb7858000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 6, 0x6) = 0xb7858000
close(6)=
0
open(/lib/libc.so.6, O_RDONLY)=
6
read(6,
\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\340l\1\0004\0\0\0...,
512) = 512
fstat64(6, {st_mode=S_IFREG|0755, st_size=1540581, ...}) =
0
mmap2(NULL, 1337608, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 6,
0) = 0xb770a000
mmap2(0xb784b000, 12288, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 6, 0x141) = 0xb784b000
mmap2(0xb784e000, 10504, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb784e000
close(6)=
0
open(/lib/libpthread.so.0, O_RDONLY) =
6
read(6,
