I store my mail/news archives on VFAT partition to be available for both Debian and Win95. I also like to modify some of them (like personal phone directory) with ci/co. Today I decided to check logs and found a problem: If I create library file in /dos/h/RCS/ by root the assigned name is "phones.txt,v" . The same operation by normal user (member of group of direcory owner - econfig) cause fault of "phones.txt,v" name but store as ",phones.txt,": I should mentioned that it was no "phones.txt,v" file at this moment ! The co -l does not work with new name format - "RCS/,phones.txt,": The directory permissions (after ci -u by local user) are: /dos/h drwxrwxrwx 21 root econfig 4096 Dec 24 20:47 . drwxrwxrwx 31 root econfig 18432 Dec 15 20:09 .. drwxrwxrwx 2 root econfig 4096 Dec 24 20:45 RCS -r--r--r-- 1 root econfig 27903 Dec 24 20:36 phones.txt /dos/h/RCS -rw-rw-rw- 1 root econfig 28152 Dec 24 20:45 ,phones.txt, drwxrwxrwx 2 root econfig 4096 Dec 24 20:45 . drwxrwxrwx 21 root econfig 4096 Dec 24 20:53 .. I always did the operation by root before and it was no RCS subdirectory. Today I tried to do everything by local user and the ci/co programs produce a lot of messages and seems does not operate at all. Filesystem info: Filesystem 1k-blocks Used Available Use% Mounted on /dev/hda3 130792 103757 20282 84% / /dev/hda1 260764 188172 72592 72% /DOS /dev/hda5 87227 73022 9217 89% /hda5 / drwxr-xr-x 26 root root 1024 Dec 13 19:21 . drwxr-xr-x 26 root root 1024 Dec 13 19:21 .. drwxrwxrwx 31 root econfig 18432 Dec 15 20:09 DOS lrwxrwxrwx 1 root root 4 Dec 13 19:21 dos -> /DOS Pavel.
============================= INIT ===============================
execve("/usr/sbin/gpm", ["/usr/sbin/gpm", "-m", "/dev/psaux", "-t", "ps2", "-D"], [/* 24 vars */]) = 0
brk(0) = 0x805a3b4
open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY) = 4
fstat(4, {st_mode=S_IFREG|0644, st_size=3367, ...}) = 0
mmap(NULL, 3367, PROT_READ, MAP_PRIVATE, 4, 0) = 0x40013000
close(4) = 0
open("/lib/libc.so.6", O_RDONLY) = 4
fstat(4, {st_mode=S_IFREG|0755, st_size=936696, ...}) = 0
read(4, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\4\211\1"..., 4096) = 4096
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40014000
mmap(NULL, 898908, PROT_READ|PROT_EXEC, MAP_PRIVATE, 4, 0) = 0x40015000
mprotect(0x400e9000, 30556, PROT_NONE) = 0
mmap(0x400e9000, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 4, 0xd3000) = 0x400e9000
mmap(0x400ed000, 14172, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x400ed000
close(4) = 0
munmap(0x40013000, 3367) = 0
personality(PER_LINUX) = 0
getpid() = 389
setuid(0) = 0
brk(0) = 0x805a3b4
brk(0x805a47c) = 0x805a47c
brk(0x805b000) = 0x805b000
open("/var/run/gpm.pid", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/dev/tty0", O_WRONLY) = 4
ioctl(4, TIOCLINUX, 0x8056d80) = 0
close(4) = 0
open("/dev/psaux", O_RDWR|O_NONBLOCK) = 4
fcntl(4, F_GETFL) = 0x802 (flags O_RDWR|O_NONBLOCK)
fcntl(4, F_SETFL, O_RDWR) = 0
rt_sigaction(SIGTERM, {0x804c080, [], SA_RESTART|0x4000000}, {SIG_DFL}, 8) = 0
rt_sigaction(SIGINT, {0x804c080, [], SA_RESTART|0x4000000}, {SIG_DFL}, 8) = 0
rt_sigaction(SIGUSR1, {0x804c080, [], SA_RESTART|0x4000000}, {SIG_DFL}, 8) = 0
rt_sigaction(SIGWINCH, {0x804c080, [], SA_RESTART|0x4000000}, {SIG_DFL}, 8) = 0
socket(PF_UNIX, SOCK_STREAM, 0) = 5
unlink("/dev/gpmctl") = -1 ENOENT (No such file or directory)
bind(5, {sin_family=AF_UNIX, path="/dev/gpmctl"}, 13) = 0
chmod("/dev/gpmctl", 0777) = 0
open("/dev/tty0", O_RDONLY) = 6
ioctl(6, TIOCGWINSZ, {ws_row=25, ws_col=80, ws_xpixel=0, ws_ypixel=0}) = 0
close(6) = 0
listen(5, 5) = 0
rt_sigaction(SIGPIPE, {SIG_IGN}, {SIG_DFL}, 8) = 0
select(6, [4 5], NULL, NULL, {86400, 0}) = 1 (in [4], left {86398, 670000})
============================= BEFORE LOCK ===============================
open("/dev/tty0", O_RDONLY) = 6
ioctl(6, KDGETMODE, 0xbffff8bc) = 0
close(6) = 0
read(4, "\0", 1) = 1
read(4, "\0\0", 2) = 2
open("/dev/tty0", O_RDONLY) = 6
ioctl(6, VT_GETSTATE, 0x8057d50) = 0
ioctl(6, TIOCLINUX, 0xbffffa61) = 0
close(6) = 0
gettimeofday({946116633, 579507}, NULL) = 0
select(6, [4 5], NULL, NULL, {86400, 0}) = 1 (in [4], left {86399, 820000})
open("/dev/tty0", O_RDONLY) = 6
ioctl(6, KDGETMODE, 0xbffff8bc) = 0
close(6) = 0
read(4, "\20", 1) = 1
read(4, "\376\2", 2) = 2
select(5, [4], NULL, NULL, {0, 0}) = 0 (Timeout)
time(NULL) = 946116633
select(6, [4 5], NULL, NULL, {86400, 0}) = 1 (in [4], left {86399, 980000})
open("/dev/tty0", O_RDONLY) = 6
ioctl(6, KDGETMODE, 0xbffff8bc) = 0
close(6) = 0
read(4, "\20", 1) = 1
read(4, "\376\6", 2) = 2
select(5, [4], NULL, NULL, {0, 0}) = 0 (Timeout)
time(NULL) = 946116633
select(6, [4 5], NULL, NULL, {86400, 0}) = 1 (in [4], left {86399, 990000})
open("/dev/tty0", O_RDONLY) = 6
ioctl(6, KDGETMODE, 0xbffff8bc) = 0
close(6) = 0
read(4, "\20", 1) = 1
read(4, "\377\17", 2) = 2
select(5, [4], NULL, NULL, {0, 0}) = 0 (Timeout)
time(NULL) = 946116633
select(6, [4 5], NULL, NULL, {86400, 0}) = 1 (in [4], left {86399, 980000})
open("/dev/tty0", O_RDONLY) = 6
ioctl(6, KDGETMODE, 0xbffff8bc) = 0
close(6) = 0
read(4, "\0", 1) = 1
read(4, "\1\22", 2) = 2
select(5, [4], NULL, NULL, {0, 0}) = 0 (Timeout)
open("/dev/tty0", O_RDONLY) = 6
ioctl(6, VT_GETSTATE, 0x8057d50) = 0
ioctl(6, TIOCLINUX, 0xbffffa61) = 0
close(6) = 0
open("/dev/tty0", O_WRONLY) = 6
ioctl(6, TIOCLINUX, 0xbffff9e1) = 0
close(6) = 0
select(6, [4 5], NULL, NULL, {86400, 0}) = 1 (in [4], left {86400, 0})
open("/dev/tty0", O_RDONLY) = 6
ioctl(6, KDGETMODE, 0xbffff8bc) = 0
close(6) = 0
read(4, "\0", 1) = 1
read(4, "\3\25", 2) = 2
select(5, [4], NULL, NULL, {0, 0}) = 0 (Timeout)
open("/dev/tty0", O_RDONLY) = 6
ioctl(6, VT_GETSTATE, 0x8057d50) = 0
ioctl(6, TIOCLINUX, 0xbffffa61) = 0
close(6) = 0
open("/dev/tty0", O_WRONLY) = 6
ioctl(6, TIOCLINUX, 0xbffff9e1) = 0
close(6) = 0
select(6, [4 5], NULL, NULL, {86400, 0}) = 1 (in [4], left {86399, 990000})
open("/dev/tty0", O_RDONLY) = 6
ioctl(6, KDGETMODE, 0xbffff8bc) = 0
close(6) = 0
read(4, "\0", 1) = 1
read(4, "\7\23", 2) = 2
select(5, [4], NULL, NULL, {0, 0}) = 0 (Timeout)
open("/dev/tty0", O_RDONLY) = 6
ioctl(6, VT_GETSTATE, 0x8057d50) = 0
ioctl(6, TIOCLINUX, 0xbffffa61) = 0
close(6) = 0
open("/dev/tty0", O_WRONLY) = 6
ioctl(6, TIOCLINUX, 0xbffff9e1) = 0
close(6) = 0
select(6, [4 5], NULL, NULL, {86400, 0}) = 1 (in [4], left {86400, 0})
open("/dev/tty0", O_RDONLY) = 6
ioctl(6, KDGETMODE, 0xbffff8bc) = 0
close(6) = 0
read(4, "\0", 1) = 1
read(4, "\4\v", 2) = 2
select(5, [4], NULL, NULL, {0, 0}) = 0 (Timeout)
open("/dev/tty0", O_RDONLY) = 6
ioctl(6, VT_GETSTATE, 0x8057d50) = 0
ioctl(6, TIOCLINUX, 0xbffffa61) = 0
close(6) = 0
open("/dev/tty0", O_WRONLY) = 6
ioctl(6, TIOCLINUX, 0xbffff9e1) = 0
close(6) = 0
select(6, [4 5], NULL, NULL, {86400, 0}) = 1 (in [4], left {86399, 990000})
open("/dev/tty0", O_RDONLY) = 6
ioctl(6, KDGETMODE, 0xbffff8bc) = 0
close(6) = 0
read(4, "\0", 1) = 1
read(4, "\1\4", 2) = 2
select(5, [4], NULL, NULL, {0, 0}) = 0 (Timeout)
time(NULL) = 946116633
select(6, [4 5], NULL, NULL, {86400, 0}) = 1 (in [4], left {86399, 990000})
open("/dev/tty0", O_RDONLY) = 6
ioctl(6, KDGETMODE, 0xbffff8bc) = 0
close(6) = 0
read(4, "\0", 1) = 1
read(4, "\1\1", 2) = 2
select(5, [4], NULL, NULL, {0, 0}) = 0 (Timeout)
time(NULL) = 946116633
select(6, [4 5], NULL, NULL, {86400, 0}) = 1 (in [4], left {86399, 690000})
open("/dev/tty0", O_RDONLY) = 6
ioctl(6, KDGETMODE, 0xbffff8bc) = 0
close(6) = 0
read(4, "\2", 1) = 1
read(4, "\0\0", 2) = 2
open("/dev/tty0", O_RDONLY) = 6
ioctl(6, VT_GETSTATE, 0x8057d50) = 0
ioctl(6, TIOCLINUX, 0xbffffa61) = 0
close(6) = 0
gettimeofday({946116634, 297983}, NULL) = 0
open("/dev/tty0", O_WRONLY) = 6
ioctl(6, TIOCLINUX
============================= END ===============================
Please note that trace message about ioctl was not finished in strace
log !!! The whole log (150K) is also available.
Pavel.
I think you sent this to the wrong bug number? This doesn't seem to have much to do with the rcs bug you reported.
I've encountered the same problem, and found that it goes away if the "quiet" option is specified, when mounting the vfat file system. This is, I guess, evidence in favour of the suspicion which led me to try this in the first place: namely that rcs is doing a chmod or chown which, in a vfat context, isn't really necessary, but which, if reported in an error message from the fs, causes rcs to bomb out. As long as nobody tells rcs about the failure of the chmod or chown, it seems fine. If you're going to try this, I guess you should follow the advice of the mount manpage, and exercise caution in using the "quiet" option; there might be a program out there doing a chmod or chown which _is_ necessary, and you might run into trouble if its failure doesn't get reported. Hope this is still some use, all this time after the bug was reported. Dan Hatton ================================================================================ Daniel C. Hatton B.A., M.Sci. (Cantab.) Research Student, Thin Film Magnetism E-Mail: dan.hatton@btinternet.com World-Wide Web: http://www.bib.hatton.btinternet.co.uk/dan/ Surface Mail: Wolfson Court, Girton College, Clarkson Road, Cambridge, UK. CB3 0EH ================================================================================
This bug has been open for a long time; it's time to close it one way
or another.
Possible fixes (assuming that fchmod/chmod is the culprit; can be
tested by commenting out the chmod stuff in the source):
o If fchmod fails, then try fstatfs to check filesystem type; if
msdos/vfat/... then ignore error.
Disadvantages:
- There's no reliable way of testing filesystem type. AFAICT
from linux-2.2.17 source, statfs's f_type will have the same
value for all FAT-based filesystems including chmod-supporting
umsdos.
- It's not clear that filesystem-doesn't-support-chmod be
considered any different from other fchmod errors.
o Unconditionally ignore fchmod/chmod errors.
o Have a flag to ignore fchmod/chmod errors.
o Have a flag to not attempt fchmod/chmod. (Does such a flag
already exist?)
o Mark the bug as wontfix, so that at least developers don't use up any
more time considering the bug.
pjm.
I'll look into whether it does exist. If not then I think is the best "solution". Not that adding such a flag would be difficult, I just don't think supporting crap filesystems is worth putting any effort in for.
tags 53434 upstream wontfix thanks Supporting vfat is not worth the effort, this bug is thus marked wontfix.
Dear Entrepreneur, This brief introductory letter may come to you as a big surprise, but I believe it is only a day that people meet and become great friends and business partners. On behalf of my son, I am searching for business with good return to invest a reasonable amount. If you have profitable project hesitate not to draw my attention for more discussions. Thanking you in advance Yours Sincerely, Mr.Gray Wayne +15622030899
Dear Entrepreneur, I want to connect with you to explore the business opportunity in the near future. Can we discuss it? Thanking you in advance Yours Sincerely, Mr.Etudes Barnon +15622030899 Strategic Partnership development NY USA
Good day, Please, am seriously looking for a profitable business where I can invest in a very lucrative and profitable venture. I will be waiting for your positive investment idea/advice. Kindly forward me your direct telephone contact for our easy discussion and further arrange on ways forward to utilize my investment funds I look forward to hearing from you soon. Looking for investment advice Thanks. Mr.Mohammed Sultan
Compliments to you, I am a financial consultant and have Investors who are willing to invest abroad and willing to provide funding for project development which could be by loan or by joint venture partnership. Kindly get back to me for more details and can we discuss? Thanking you in advance Yours Sincerely, Mr. Mohammed Sultan +27603187672 Strategic Partnership development (ADP)
Compliments to you, I am a financial consultant and have Investors who are willing to invest abroad and willing to provide funding for project development which could be by loan or by joint venture partnership. Kindly get back to me for more details and can we discuss? Thanking you in advance Yours Sincerely, Mr. Mohammed Sultan +27603187672 Strategic Partnership development (ADP)