Renaming files

[dbo]

To avoid naming collisions and add a bit of security I'm generating filenames based off of an md5 hash. It works all fine and dandy until I try to use the rename function on the hash. Apparently there is a maximum length to a filename or something in rename because the rename is failing. I try it on a file representing the first 8 digits of the hash... same directory... same permissions and it works, but will not work on the full hash. Any ideas?

[dbo]

Apparently this is true of all the file functions???

[PFMaBiSmAd]

This is likely an operating system limit. What operating system are you using?

 

For Windows - http://vlaurie.com/computers2/Articles/filenames.htm

 

Edit: Here is a better link - http://www.comentum.com/File-Systems-HFS-FAT-UFS.html

[dbo]

I'm completely baffled... here's the filename:

 

This fails:

rename('./upload/5b4875453cbcb59713701e17e495de4c', './upload/32876fc3df25fb68fb9e398b5d7d7977');

 

This works:

rename('./upload/5b487545', './upload/32876fc3');

 

Certainly less than the 250ish characters I've been seeing as an OS limit.

[PFMaBiSmAd]

Your first line of code works for me on a WinXP development system using the latest php5.2 version.

 

Are you doing this on a system with full php error reporting turned on to get any php detected errors to be shown?

[dbo]

Warning: rename(./upload/5b4875453cbcb59713701e17e495de4c,./upload/32876fc3df25fb68fb9e398b5d7d7977) [function.rename]: No such file or directory in /home2/firebees/public_html/cmsbackend2/rename.php on line 4

 

The file exists though... I've tested on a Linux development box and production server... same results.

[corbin]

Try taking the ./ off of it, or try running it through realpath().  Don't know for sure if either of those will work, but worth a try.

[dbo]

Nah, I tried full paths as well, same result.

[premiso]

Weird stuff, maybe php has the limit and not the OS? not sure.

 

Anyhow you could use the exec and use the Unix commands to rename the file that way. Not ideal, but it should work.

 

A side note I would do this:

 

<?php
if (file_exists('./upload/5b4875453cbcb59713701e17e495de4c')) {
    rename('./upload/5b4875453cbcb59713701e17e495de4c', './upload/32876fc3df25fb68fb9e398b5d7d7977');
}else {
    echo 'Unable to rename the dang file cause it does not exist.';
}
?>

 

On a lighter side, I am sure it is some stupid little mistep and when you figure it out you will rip your hair out at how easy it was to find.

[corbin]

premiso, he showed us one line.  That doesn't mean he wasn't checking its existence elsewhere.

 

 

 

So dbo, you're sure the file perms are correct?

[dbo]

Yeah it's definitely a file length issue. I did a 777 on the parent directory and the file to be sure.

 

I know a workaround that doesn't involve the hash... it just kind of sucks because I was pretty pleased with this solution. Too bad I got pwnd by one of the dumbest things evah!

[corbin]

/home2/firebees/public_html/cmsbackend2/upload/5b4875453cbcb59713701e17e495de4c

 

 

Is just 79 chars....  I don't see why it would have issues with that.  That's weird.

 

 

I'm guessing the problem is specific to linux.  If so, is it just the distro that you use?  Or all distros?  Never heard of that issue before.

 

 

Edit:

 

ext/stand/file.c

/* {{{ proto bool rename(string old_name, string new_name[, resource context])
   Rename a file */
PHP_FUNCTION(rename)
{
char *old_name, *new_name;
int old_name_len, new_name_len;
zval *zcontext = NULL;
php_stream_wrapper *wrapper;
php_stream_context *context;

if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "ss|r", &old_name, &old_name_len, &new_name, &new_name_len, &zcontext) == FAILURE) {
	RETURN_FALSE;
}

wrapper = php_stream_locate_url_wrapper(old_name, NULL, 0 TSRMLS_CC);

if (!wrapper || !wrapper->wops) {
	php_error_docref(NULL TSRMLS_CC, E_WARNING, "Unable to locate stream wrapper");
	RETURN_FALSE;
}

if (!wrapper->wops->rename) {
	php_error_docref(NULL TSRMLS_CC, E_WARNING, "%s wrapper does not support renaming", wrapper->wops->label ? wrapper->wops->label : "Source");
	RETURN_FALSE;
}

if (wrapper != php_stream_locate_url_wrapper(new_name, NULL, 0 TSRMLS_CC)) {
	php_error_docref(NULL TSRMLS_CC, E_WARNING, "Cannot rename a file across wrapper types");
	RETURN_FALSE;
}

context = php_stream_context_from_zval(zcontext, 0);

RETURN_BOOL(wrapper->wops->rename(wrapper, old_name, new_name, 0, context TSRMLS_CC));
}
/* }}} */

 

It looks like it just parses the args and hands it off to the system rename function, like I would expect.  I wonder where the error is with the file name length.  Weird.

[PFMaBiSmAd]

I'm thinking there is something going on with the actual characters in the file name and not the length. Try renaming your first short file name to the second long one. If that works, it would indicate that the length is not the problem. Have you tried this with different long source and destination names or just the ones you have posted?

[dbo]

I've tried with multiple long names that are made up of md5 hashes. There are no illegal characters in the filename...

 

My distro is Ubuntu 8.04... I'm not sure what's on the production server... I'd guess Redhat.

[dbo]

I think I'll write a script that barfs all the filenames to the screen and see what that gives me.

[corbin]

Oh, errr.... the dest name doesn't already exist does it?

[dbo]

Nah... I'm not sure what changed but it seems to be working?

 

I essentially wrote a script that loops through all the files and renames the file adding a - counter to the end of the file.

 

ie

 

file => file-1

 

And the rename is working. This test was completely separate from the rest of the project, so perhaps I overlooked something else.... or maybe I just happened to look at it just right so it decided to work.

[corbin]

That's cracked out.  Seriously.