Bug 80493 - unix2dos fails when converting a file not in partition of CWD
Summary: unix2dos fails when converting a file not in partition of CWD
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: unix2dos
Version: 3.0
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Tim Waugh
QA Contact: Ben Levenson
URL:
Whiteboard:
Depends On:
Blocks: 132991
TreeView+ depends on / blocked
 
Reported: 2002-12-27 06:06 UTC by greg hosler
Modified: 2007-11-30 22:06 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-05-20 00:35:33 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
SRPM containing patch file and updated version # for fix. (11.42 KB, patch)
2002-12-27 06:08 UTC, greg hosler
no flags Details | Diff
unix2dos-2.2-fnames.patch (4.21 KB, patch)
2004-10-01 10:16 UTC, Bastien Nocera
no flags Details | Diff


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2005:195 0 low SHIPPED_LIVE dos2unix and unix2dos bug fix update 2005-05-19 04:00:00 UTC

Description greg hosler 2002-12-27 06:06:35 UTC
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)

Comment 1 greg hosler 2002-12-27 06:08:49 UTC
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.

Comment 2 Bastien Nocera 2004-10-01 10:16:23 UTC
Created attachment 104623 [details]
unix2dos-2.2-fnames.patch

Same as bug 80492 but for unix2dos.

Comment 3 Mike A. Harris 2005-01-17 17:41:11 UTC
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



Comment 4 Mike A. Harris 2005-02-08 18:54:58 UTC
Fixed in unix2dos-2.2-19.EL.24

Comment 6 Tim Powers 2005-05-20 00:35:33 UTC
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



Note You need to log in before you can comment on or make changes to this bug.