Well, renaming files should not be an issue today, given that files should be identified by their content (i.e. their SHA1 signature or the associated URN), rather than by their name.
The file name used to be necessary in old versions of Gnutella to download files by names, but this method is largely deprecated due to various filename encoding issues.
Renaming a file normally does not change its content, so it is safe for swarmed downloads (of course it will only change the name under which a file can be found for new incoming searches, but this won't harm incoming download requests by URN)

On the opposite, editing meta-data MAY change the file content and require it to be rehashed (for example when editing MP3 meta-data), meaning that the file will no longer be delivered for incoming download requests by URN (replying with 404 not found).

One bad thing is that some servents (GTKG?) attempts to retry the download when a download by content digest URN fails with 404 status, by using the old deprecated method of download by name, and if thy want swarmed downloads, the file will appear corrupted.

My opinion is that we should no longer accept incoming download requests by name, in all modern servents that supports downloads by content digest URN (we should return 404 not found if we have an URN for the file that may have been modified with its URN adjusted accordingly).

Well, you can still rename files in your OS browser, but there happens some quirks in LimeWire, because it does not detect the name change immediately. The only way to recover is to force it to refresh the directory, so that it will see the new name, will recompute the file hash (LimeWire does not know it is the same file content as before it was renamed), and then see the matching URN that can be honored again for incoming transfer requests.

But I have seen that this still leaves the file in red (unshared), if you don't refresh also the "Shared files" filtered list in the LimeWire Library.

Note however that you won't be able to rename a file as long as a upload or play is in progress. But the safest place to rename a file should be the LimeWire library, and not the Explorer, as long as LimeWire does not include a monitor for OS notifications about changes in the monitored folder. This monitoring option exists on Windows and probbly not on Linux (don't know about Mac OSX). If this monitoring was effective, we could rename safely all files from the Explorer, because LimeWire (in fact the Java Filesystem integration classes) would receive those notifications.

Renaming files
 

There's of course the obvious & simplest of reasons why a person would want to rename a file. Too often there are incorrectly/inaccurately named files being shared. 2ndly, some os's (eg: mac os9) which have a limit on the length of name. A longer than legal name can cause probs.)

OK , you guys obviously know a lot more about this than me. The only time I renamed a file was when I was a kazaa user (gag) ... I came across a game that took 3 days to download and it was a completely different game. I renamed it to "THIS IS NOT xxxxxx" and purposely kept it in the download folder so that other people would know. (On kazaa you can see all the sources and the individual file names) This led to a lot of messages from users asking me if the content was correct and I saved loads of people from downloading it.
The main problem was there was about 75 sources of this incorrectly named file.
Of course, I don't have the time to police the whole network!!! ;)

Another reason for renaming files is effectively the presence of fake files, whose names are returned matching exactly the query, but whose content is advertizing for some porn sites.
These files are easy to detect: lots of people share them without verifying the content, and so these files have unusually high number of sources (100 or more, matching the same SHA1 signature).
This affects mostly small video files (around 3 to 5 MB), but I have seen recently some fake Windows Media Audio files, that contain automatic links to these porn sites.
May be we should think about creating a distributed database of files identified by their SHA1 or URN with such deceptive unrelated contents.
For now one of the surest ways to detect fake files is that their name match exactly the query string: in LimeWire, query strings that are sent are formatted in lowercase, with no punctuation, and single separation spaces, and no common short keyword like "a" or "on" or "is". A query hit without significant meta-data and no verbose description, and a size below 5MB, and lots of sources (more than 30) is almost always a fake deceptive file.

Looks like the memory is still a problem with OS X.

Running jum353 over for a day eventually ate up 2 GB of hard drive space, resulting in a "out of disk space error", and eventually a java crash sent to Apple. "Exception: EXC_BREAKPOINT (0x0006) "

I've saved the bug report if anyone wants it, and did manage to grab a screenshot of memory activity a few minutes before the crash

(Running as UP, about ~.5GB downloaded, ~2 GB uploaded)

[edit--overly large screenshot removed]

Salut Stief, since apple java 1.4.2 update 2, my virtual memory didn't go over 600 megs. Are you using the latest java update?

ciao

re: fake files
 

verdyp, my understanding is that these results are generated from popular searches by certain sources linking onto the search. Sure, people may dwnld these accidently, else the offender(s) for generating these files may be accumulating them (Possible source of fakes. ) Rather than just using keyword filters (eg: .wmv, .exe, .jpg), which doesn't suit people looking for files in these formats, your suggestion sounds good. Brainstorming ideas? I made a suggestion in the New Feature Requests section for a size filter to be added to LW. This can help people in more ways than one & would certainly help to block out those automatically (I suspect) generated search results that are fakes. This is the size filter suggested & its advantages: http://www.gnutellaforums.com/showth...threadid=28255

Quote from the possible source of fakes link I gave above: 'Movie Pirates take ripped versions of porn movies and publish them on the network. (Copyright-infringment). The porn industry in response to this attempts to curtail the activity by flooding the network with video-clips that advertise the websites for such material.'

Quote:

Salut Stief, since apple java 1.4.2 update 2, my virtual memory didn't go over 600 megs. Are you using the latest java update?

Salut et voilà--Happy Thanksgiving
Yes, it's the latest public release.
LimeWire version 4.1.5jum353 Pro
Java version 1.4.2_05 from Apple Computer, Inc.
Mac OS X v. 10.3.5 on ppc
Free/total memory: 34005840/89513984

I saw CPU usage had definitely improved with the update, but I wasn't sure about memory, so I planned to let LW run all weekend. FWIW, here's what memory looked like after an 11 hours run (the earlier screenshot is after a 30 hour run)

[edit--overly large screenshot removed]

Resalut Stief, maybe the CVS versions fixed that bug. How old is the jum353 build?

Ciao et bonne Action de grâce à toi aussi!

Looks like Jens-Uwe last modified jum353 07-Oct-2004 21:58. Unless I missed the fix, I figure the problem is still in the CVS.

(and happy Columbus Day to Bushlanders).