Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Lineinfile backup doesn't work on FAT32 #10591

Closed
dbrgn opened this issue Apr 1, 2015 · 5 comments · Fixed by #10593
Closed

Lineinfile backup doesn't work on FAT32 #10591

dbrgn opened this issue Apr 1, 2015 · 5 comments · Fixed by #10593
Labels
bug This issue/PR relates to a bug.

Comments

@dbrgn
Copy link
Contributor

dbrgn commented Apr 1, 2015

Issue Type:

Bug Report

Ansible Version:
ansible 1.9.0.1
  configured module search path = None
Environment:

Running on Arch Linux, managing Raspbian on a Raspberry Pi.

Summary:

When using the lineinfile module with backup=yes on a FAT32 file system, I get an exception.

It appears that some of the characters (I think at least the colon in the timestamp) are invalid on FAT32.

Steps To Reproduce:

I used the following task:

- name: Enable systemd.
  lineinfile:
    dest: /boot/cmdline.txt
    state: present
    regexp: '^(.* rootwait)$'
    line: '\1 init=/bin/systemd'
    backrefs: yes
    backup: yes
Expected Results:

It works :)

Actual Results:
Traceback (most recent call last):
  File "<stdin>", line 2199, in <module>
  File "<stdin>", line 394, in main
  File "<stdin>", line 281, in present
  File "<stdin>", line 1706, in backup_local
  File "/usr/lib/python2.7/shutil.py", line 130, in copy2
    copyfile(src, dst)
  File "/usr/lib/python2.7/shutil.py", line 83, in copyfile
    with open(dst, 'wb') as fdst:
IOError: [Errno 22] invalid mode ('wb') or filename: '/boot/cmdline.txt.2015-04-01@14:28:29~'
@dbrgn
Copy link
Contributor Author

dbrgn commented Apr 1, 2015

A possible fix would be to use a unix timestamp or alternatively 20150401142829 instead. Might this introduce reverse compatibility issues of some form?

This code could also live in a try-except block.

@bcoca
Copy link
Member

bcoca commented Apr 1, 2015

many of our file operations will fail on non POSIX file systems, still this should not be a traceback

@dbrgn
Copy link
Contributor Author

dbrgn commented Apr 1, 2015

This is very simple to fix though. So I think it's worth the effort :)

Alternatively, a way to specify the destination path for the backup file would be even better.

@bcoca
Copy link
Member

bcoca commented Apr 1, 2015

it is already in a try block, it does not capture IOErrors though, which it should.

as for this being a 'simple' fix, yes, if we wan't to break backwards compatibility, it is simple, but we don't.

bcoca added a commit to bcoca/ansible that referenced this issue Apr 1, 2015
@bcoca
capture IOErrors on backup_local (happens on non posix filesystems)
1fa3dbb 
fixes ansible#10591
@bcoca bcoca mentioned this issue Apr 1, 2015
Merged
bcoca added a commit that referenced this issue Apr 2, 2015
@bcoca
capture IOErrors on backup_local (happens on non posix filesystems)
2776588 
fixes #10591
@xiegeo
Copy link

xiegeo commented Jan 18, 2017

Please fix this, FAT32 is required in some situation, such as the raspberry pi boot partition.

An opt in option to alternative backup file names should not break backwards compatibility.

@ansibot ansibot added bug This issue/PR relates to a bug. and removed bug_report labels Mar 6, 2018
@ansible ansible locked and limited conversation to collaborators Apr 25, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
bug This issue/PR relates to a bug.
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

capture IOErrors on backup_local (happens on non posix filesystems) bcoca/ansible
4 participants
@dbrgn @bcoca @xiegeo @ansibot