Race condition in upload module

I'm lower the priority because there exist similar cases in the rest of Drupal.

It seems like the solution would be to prepend the images with the node ID, which would very much lessen the chance of this happening. This is what I have done for my own installation (with a few hacks in upload.module). Another positive is that you'll immediately know where images/uploads are being used when poking around in the /files directory.

why not fix this and more by giving uploads a more private namespace?

the single upload dir is a significant drawback in the upload module IMHO.

i'm attempting to modify the module so that an admin can optionally choose to create unique dirs on a per user and node basis.

files would go in [files]/$userid/$nodeid/ instead of [files]/

but i'm having quite the time trying to do this. it definitely shouldn't be difficult thing to do, but the code is pretty difficult to follow because the upload destination directory is calculated multiple times (for the same info).

also see:
http://drupal.org/node/28769

Any updates with this issue?

Dries said this was a global issue, updating the status. Haven't run into this myself but I see the possible problem. Can anyone confirm this?

What about a patch?

Any news about this? I think there were introduced several new features to avoid race conditions.

FYI/alternative: http://drupal.org/project/attachment
("Thread safe - This module prevents users from accidentally seeing other users uploads")

The idea of using one directory for all files is only good for small sites with few users.
Just imagine: you got many users that create their own nodes, they edit the node with WYSISYG and want to add picture or flash to the node and/or attach several files. current drupal's file system is not going to be effective. I looked at modules called, attachment and filemanager. they are not well maintained, are not (well) documented and are not going to be ported to Drupal 5.x.

If we want to have/create a good file/attachment management system, we need to go through 2 steps, First creation and second creation. First creation also called mental creation is to creating ideal mental image of what we want, then with having the first creation we start the second creation also called physical creation.
let's work together on the mental creation, please add the features you need and implementation path you suggest and your reasoning

Features :
-Supports limitations by each roles.
-can deal with same filename.ext added by same user/different user
-Supports history version of files
-have check in/out for each file
-Don't make it complicated for smaller sites
-Support other languages characters
-size limitation by node/user
-extension limitation by node/user
-ability to deal with space in the filename
-files can be saved somewhere other than Drupal directory

Implementation path:
- use a path like flies/node/[node#] for storing files related to a node*
*because everything is a node in Drupal, I think its better to use such a path, node# directory with all it's files will be deleted if someone delete the node
- use a path like flies/user/[user#] for storing files related to a user, user# directory with all it's files will be deleted if someone delete the user
- use database tables to save file attribute (hidden, read only, checked out, etc) and file history (who modified, modification time stamp, etc)

seems to be a huge issue.
any word on this?

Still no solution for this issue?
I've tried using uploadpath module http://drupal.org/project/uploadpath but it seemed that it still have bugs http://drupal.org/node/133570

I've ask this kind of question in the forum but still got no answer after 2 days.
http://drupal.org/node/133122

As far as I can see this problem does not exists in the current CVS version.

Then its fixed.

subscribing