Re: letting a browser client select a file to download by inode

Erm, that just strikes me as a bad idea. It's the same reason you don't use a "product number" or similar external identifier as a primary key: it's subject to change outside the database that's just begging to get out of sync. What happens if you move to a different machine (or even just a different filesystem on the same box)? What happens if the drive crashes and things get reloaded from a backup? You've just set yourself up to write more code to deal with these contingencies (which means more development time, more testing (and are you really sure you've covered all the cases?)).

Just seems like you're being overly clever to "save" yourself or your DB from doing a trivial bit of work. If you want something tied to the file itself an MD5 or the like would be a better choice than the inum.

Comment on Re: letting a browser client select a file to download by inode

Replies are listed 'Best First'.
Re^2: letting a browser client select a file to download by inode by leocharre (Priest) on Dec 27, 2005 at 13:41 UTC
Yes I am being clever. Sometimes being clever and using bits and pieces of what the community has offered (ext 3 in this case) is what open source is all about- but then sometimes you are simply.. being clever for no good reason. Isn't inode the way that ext3 and it's db trusts to keep up with what files are in the system? If it's good enough for my computer, shouldn't it be good enough for everything else ? This is why I thought maybe this was indeed the right way to go; because inode is the way that the machine keeps track of the files. And I kind of trust it more then me. The environment is one of file-sharing with specific people. People who know little about machines (windows users) will be creating these files to share with even less computer savvy people (more windows users) - on a per person basis. The people creating the files have power to- through the filesystem; rename the files! There has to be a way to keep track of the file. MD5 had some problems in 2004, some stuff about collisions .. dunno.. not my field.. but.. Is it still safe to check data on MD5 sum? - incredibly interesting suggestion!	[reply]
Re^3: letting a browser client select a file to download by inode by esskar (Deacon) on Dec 27, 2005 at 15:54 UTC
no, MD5 is not the choice but any better digest function may be it. I suggest SHA512 (well, you could also use SHA256 - there is also a SHA384 but it's just the same as calculating SHA512 and throwing away the extra bits) <edit>typo fixed</edit>	[reply]
Re^3: letting a browser client select a file to download by inode by eric256 (Parson) on Dec 27, 2005 at 16:16 UTC
Sure its good enough for the file system. Applications however use filenames because those wont change even if you have to delete and recreate files, or reload files from back, or install a new hard drive etc. You could always store the location and the inode, then use your inode link to update names when they change the filename on the system. Or you could give them a web based way to change the name so that you can keep track of it that way. ___________ Eric Hodges	[reply]
Re^3: letting a browser client select a file to download by inode by tirwhan (Abbot) on Dec 27, 2005 at 17:24 UTC
Is it still safe to check data on MD5 sum? For this purpose absolutely. The collision attack that was discovered against MD5 means that some very smart people have managed to create two different bits of data which produce the same MD5 hash. The creation of a modified file the MD5 of which matches that of an existing, "real-world" file is as yet only theoretically possible. And the chance of this happening by accident on your machine is less than that of your server, all backups and your pants spontaneously combusting :-). A computer is a state machine. Threads are for people who can't program state machines. -- Alan Cox	[reply]