Mikulas Patocka <[EMAIL PROTECTED]> wrote: > On Sat, 30 Dec 2006, Paul Eggert wrote: >> Mikulas Patocka <[EMAIL PROTECTED]> writes: >> >>> BTW. could it be possible to change POSIX on this issue? >> >> I very much doubt it. POSIX deliberately does not specify the >> behavior of non-POSIX file systems, or of programs operating on >> non-POSIX file systems. That's out of scope, just as it'd be out of >> scope for (say) the US Congress to legislate French foreign policy. >> (Not that they haven't tried....) > > The question is then why to follow POSIX? It is a shame that such a simple > operation as copying a file from floppy diskette or usb stick has a race > condition ... thanks to standartization committee.
Since most file systems *do* conform to POSIX when it comes to inode numbers, it is only natural that tools like those in gnulib and coreutils take advantage of whatever integrity checks they can, to better protect against abuse and/or misuse. If removing the inode-related checks would make programs less useful on reliable file systems, or if testing whether to remove those checks at run time would impose a noticeable cost on systems that do have useful inode numbers, then why should we bother? The risk of your race condition is very low and affects only 2nd (3rd?) class file systems like FAT. However, it is possible to rewrite copy.c so that there is no race between the stat and open calls for regular files. However, it's a big and thankless job. That would make a good student project. Ideally, if someone does this, they will take the time to ensure better test coverage _first_. _______________________________________________ Bug-coreutils mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-coreutils
