GNOME Bugzilla – Bug 309584
"invalid parameter" while copying to vfat if name has one of " ? : * | < > / \\
Last modified: 2008-08-04 09:11:30 UTC
This bug has been opened here: https://bugzilla.ubuntu.com/12294 "I was trying to copy a file with a '?' in the filename to my vorbis player which is a USB device (nicely automounted by Ubuntu) with a VFAT filesystem on it. --------------------------------------- Error While Copying --------------------------------------- Error "Invalid parameters" while copying "/home/desrt...iou.ogg". Would you like to continue? [ Skip ] [ Cancel ] [ Retry ] --------------------------------------- This error message confuses me an awful lot. As far as I know, I'm performing a valid operation to a device that has enough free space. I don't know that VFAT doesn't support certain characters and this error message doesn't make that fact any more obvious to me. The only-slightly-guessable filename isn't even the one that had the '?' in it (and in fact, the shown filename was transfered successfully!). More to the point: it should 'just work'. Something (nautilus, kernel) should just change the ? to a _ or remove it entirely. I tried adding 'check=relaxed' to the mount options (which the mount manpage seems to suggest might help) but it had no effect."
I can confirm this on 2.10.1, and it's a royal pain to change the names of files to copy over. Moreso, since sound juicer doesn't have an option to convert some characters to safe ones. Its 'strip special characters' mode does replace characters that are problematic on vfat, but also replaces spaces, which is annoying.
It'd be nice if Nautilus could detect if it was copying to a VFAT filesystem and drop the problem characters or replace them with '_' or something.
*** Bug 312675 has been marked as a duplicate of this bug. ***
According to [1], only ASCII characters are supported by VFAT. The question mark is within the first 128 characters, so I don't see why we fail at all. What about the characters 129-256? Do we have some kind of code page support on our systems? [1] http://averstak.tripod.com/fatdox/names.htm
I am also seeing this to when copying a file called 03 - Shantel "Bucovina".ogg I can work around it by removing those quote characters from the name. ? characters also cause this problem. ü (u with an umlaut) works fine. This is Ubuntu Dapper.
I'm reassigning this to GnomeVFS, because of the following analysis: When trying to create a file on a VFAT FS, the linux vfat source code checks for bad characters using static inline wchar_t vfat_bad_char(wchar_t w) { return (w < 0x0020) || (w == '*') || (w == '?') || (w == '<') || (w == '>') || (w == '|') || (w == '"') || (w == ':') || (w == '/') || (w == '\\'); } It will then return EINVAL. We probably have to introduce a GnomeVFS error signalling that the target FS is a FAT FS, AND that a bad character occured, so that we can retry with another filename, escaping the characters. The relevant place for triggering the error is probably inter alia in GnomeVFS, modules/file-method.c:rename_helper, and some other places where g_stat's retval is checked. We'd have to check for EINVAL, and additionally for the target file system being a VFAT FS, using a filesystem_type helper on the statbuf of the target directory. The Xfer code would then retry (once!) with a modified, escaped version. Milestoning to 2.16 because it requires a new GnomeVFSResult, and thus is an API freeze breakage. It would be great if somebody volunteered for this task, I can give further advice.
> and additionally for the target file system being a VFAT FS, using a > filesystem_type helper on the statbuf of the target directory. Is there an example of that somewhere else in gnome-vfs?
>> and additionally for the target file system being a VFAT FS, using a >> filesystem_type helper on the statbuf of the target directory. > Is there an example of that somewhere else in gnome-vfs? modules/file-method.c:do_is_local If you're interested in the actual code for determining the file system, it is in modules/fstype.c. Note that I proposed the GnomeVFSResult strategy, because simply falling back to another filename in the actual method implementation without letting the outer world know isn't viable - the outer world assumes that after the method function invocation, the passed-in target URI still correctly refers to the target file, which isn't the case when you randomly modify the target upon stat failure. You will probably also have to add a char * _gnome_vfs_uri_escape_vfat_characters (const char *path); helper to libgnomevfs/gnome-vfs-private-utils.h escaping the characters mentioned in comment 6. Maybe you could replace them by '?' in a first step and then run gnome_vfs_escape_set (string, "?") on the result string - otherwise the '?' would identify a URI fragment.
Sorry, I accidentally suggested to use '?' in comment 8 which itself is a bad character. '_' should work, as proposed in the original bug report.
Sorry for the bug spam, but I'd just like to add that you don't have to run gnome_vfs_escape_set on the resulting string when using '_', it is not a reserved URI character ("reserved" as of RFC 2396).
Created attachment 78881 [details] [review] gnome-vfs-2.17.2-vfat.patch First step to fix this: Create a method that escapes the string. This is a (possibly wrong, insecure and inefficient) attempt on creating a method to create a new string that has all the 'wrong' characters replaced. I have tested it to compile and a bit for correctness. Please note that I really suck at C and especially at string operations. Currently it does not allow german umlauts ('ö', 'ä', etc.) since their char value is below 0 (-20, -35, etc.) so the check "w < 0x0020" eliminates them. This might be solved by checking with "((w < 0x0020) && (w >= 0x0000)) || ..." but that might introduce unwanted characters so I left it out. Please comment on this starting patch (my first patch to gnome)!
+ for (; in_ptr < (path + strlen(path)); in_ptr++, out_ptr++) { + char w = *in_ptr; + if ((w < 0x0020) + || (w == '*') || (w == '?') || (w == '<') || (w == '>') + || (w == '|') || (w == '"') || (w == ':') || (w == '/') + || (w == '\\')) { + *out_ptr = '_'; + } else { + *out_ptr = *in_ptr; + } this seems to be about the right idea.... of course, you face certain issues to do with the fact that you're effectively creating a new equivilence class of filenames.... although, vfat is already weird in that 'A' == 'a', so having '?' be the same as '>' is really only an extension of that weirdness.... the stuff for < 0x0020 is weird. i'm not sure why any user would ever have these characters in any filename and this twist just seems likely to introduce odd bugs.
Created attachment 79621 [details] Error message Hi, I was going to report something about this. Here is the message box I get: how am I supposed to find which file caused this error? This happens when copying a huge directory, with many subdirectories. I know this is caused by a wrong encoding, but here my problem is that the error message is unusable. Actually, this might even be considered as a separated issue. So perhaps a quick fix would be to provide the whole error message to the user, especially the complete file path.
*** Bug 163288 has been marked as a duplicate of this bug. ***
Perhaps someone could see if my bug 373083 should be marked as a duplicate of this bug? It seems to be the same to me, thanks.
*** Bug 373083 has been marked as a duplicate of this bug. ***
Just as an update, I just ran into this problem running Fedora 7 with Gnome 2.18.13. I share F. Ingelrest's thoughts on the error message being difficult to read (because the box it's in isn't big enough if the copied path has many characters). Using cp from the command line will give you useful errors though. Let this also be a warning to any other users like me who thought that cp was a workaround, because if you happen to use cp -v, you might not notice error output amongst all the other output you ask for.
I haven't understood much of the discussion about this bug but it really annoys me. It sounds like there are some complex issues but can't we start with doing something? So here's a workaround suggestion, could be done in this order of priority: 1st. Change 'Invalid parameters' to a message that means something. Perhaps "File/ folder name contains invalid characters for the filesystem you are trying to write to" 2nd. Widen the error message so it includes more of the file name (preferably the whole filename) 3rd. Add a 'Rename' button which lets me rename the file to try a different name 4th, 5th and 6th... The final whizbang solution which is complicated and won't happen any time soon. :-)
Ran into this using Nautilus 2.18.1 on Ubuntu Feisty Fawn when trying to copy music files to a SMB share. I agree that filenames shouldn't be changed behind the scenes but a "Rename files on copy/move if the filename is invalid on destination file system" option in behavior tab of the preferences might be acceptable along with a more descriptive error. Just as a note, the following find command run from my music root directory sorted the problem for me: find . -iname "*" -exec rename -v 's/\:|\*|\?|\"//g' "{}" \;
the bug has been fixed in nautilus now http://svn.gnome.org/viewvc/nautilus?view=revision&revision=14438