Red Hat Bugzilla – Bug 80493
unix2dos fails when converting a file not in partition of CWD
Last modified: 2007-11-30 17:06:55 EST
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 Description of problem: unix2dos fails to convert a file which is in a partition different from the current working directory. (while untested, it probably also fails if cwd is invalid, e.g. mkdir ./tmp; cd tmp; rmdir `pwd`; dos2unix <path>/foo). specifically the error message will be something like: # unix2dos /tmp/a.b.c unix2dos: converting file /tmp/a.b.c to DOS format ... unix2dos: problems renaming './u2dtmpy3s55u' to '/tmp/a.b.c' output file remains in './u2dtmpy3s55u' unix2dos: problems converting file /tmp/a.b.c Analysis shows that the temp file created is of the form, "./u2dtmpXXXXXX" which receives the converted text. After the conversion, the original file is unlinked, and the temporary file is rename()'d to the original filename. This fails with errno=18 (EXDEV, Cross-device link) when the target file is not in the same partition as the CWD. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. create a temporary file on a partition, different from the CWD partition. (or create a file, and then cd to a different partiton). 2. unix2dos <that file> Actual Results: original file deleted, results in temp file in present directory. Expected Results: original file should be converted, and there shold be no need for the user to "mv ./u2d<random> <the original target filename>". Additional info: I have looked at various older unix2dos source archives. This is a long standing bug. I have generated a fix, and include the patch (and updated spec file) in the attached SRPM This is related to the same bug in unix2dos (bugzilla @80492)
Created attachment 88941 [details] SRPM containing patch file and updated version # for fix. proposed patch creates the temp file in the same directory as the original file, generally guaranteeing that the rename() will succeed.
Created attachment 104623 [details] unix2dos-2.2-fnames.patch Same as bug 80492 but for unix2dos.
unix2dos and dos2unix have a number of open issues in bugzilla currently, and new ones seem to be discovered more and more with the new tools available on current generation distributions. There are a variety of problems with these utilities, roughly in order: 1) There is no upstream maintainer or canonical source, nor new versions released by the previous maintainers. Our rpm is more or less a custom Red Hat fork-by-patch-accumulation effort, which over time is becoming a bit of a mess (IMHO). 2) As we fix bugs, the fixes haven't gotten propagated back to older OS releases as erratum, so some of the same bugs get found and reported on older OS releases again, etc. 3) The code is kindof ugly/wonky, and could really use a cleanup, security audit, stability/reliability audit. They're both simple utilities, which makes it a bit humorous there is so much wrong with them. ;o) I'm going to review all open issues with these utils, figure out which ones are relevant for FC4 dos2unix/unix2dos, and apply patches, create new fixes, etc. and consider putting them in CVS on sourceforge or somewhere external. Defering this until Jan 24th, but still targetting for RHEL3_U5
Fixed in unix2dos-2.2-19.EL.24
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2005-195.html