[java] problemi con alcuni file e cartelle invisibili

[Prince_81]

Ciao a tutti,
volevo chiedervi come mai mentre cerco di visualizzare file e cartelle con il seguente codice:


File file=new File("C:\\");
File f[]=file.listFiles();

for(int i=0;i<f.length;i++){
if(!f[i].isHidden()){
System.out.println(f[i].getPath());
}
}



nonostanche abbia usato l'istruzione if(!f[i].isHidden()) alcune cartelle e alcuni file di sistema o semplicemente invisibili vengono visualizzati nell'output?

[banryu79]

Sistema operativo?

Secondo la documentazione del metodo isHidden in java.io.File il fatto che un file sia hidden dipende da cosa il so/file system sottostante consideri come hidden.
Prova a stampare a parte i file considerati hidden e confrontali con quelli che non sono considerati tali ma che tu ti aspetti lo siano.

[Prince_81]

il sistema operativo è windows, ma cosa dovrei confrontare poi? per esempio la cartella Document and Settings è invisibile però viene stampata, poi c'è il file autoexec.bat che pure è invisibile.

[sottovento]

il sistema operativo è windows, ma cosa dovrei confrontare poi? per esempio la cartella Document and Settings è invisibile però viene stampata, poi c'è il file autoexec.bat che pure è invisibile.

Sul mio sistema (win 7, jdk1.7.0_11) alcuni file/cartelle invisibili vengono mostrati, altri no.

C'era un bug di vecchia data, restato per quanto ne so, irrisolto:
http://bugs.sun.com/view_bug.do?bug_id=5029353

Ce n'era anche un altro relativo al fatto che questo metodo sbagliava ancora quando il file era hidden e write-protected, ma non riesco a trovarlo

[Prince_81]

non esiste un metodo in java per capire se un file o una cartella è di sistema?

[sottovento]

non esiste un metodo in java per capire se un file o una cartella è di sistema?

No. Non mi risulta sia una proprieta' messa a disposizione dal S.O.

http://stackoverflow.com/questions/12051922/check-if-a-file-is-a-system-os-file

Puoi sempre girarci intorno: su internet ci sono dei siti che forniscono informazioni sui file di Windows/Linux (librerie condivise, ....).
Potresti collegarti ad uno di loro automaticamente e verificare il file sotto esame

[Vincenzo1968]

Non è meglio scriversi una bella dll in C? Una funzioncina da richiamare tramite JNI?

http://www.hwupgrade.org/public/style_emoticons/default/challenge.png

Bug irrisolto http://www.hwupgrade.org/public/style_emoticons/default/lol.png

Nientedimeno dalla versione 4(e siamo alla 7) http://www.hwupgrade.org/public/style_emoticons/default/lol.png

[sottovento]

Non è meglio scriversi una bella dll in C? Una funzioncina da richiamare tramite JNI?

http://www.hwupgrade.org/public/style_emoticons/default/challenge.png

Bug irrisolto http://www.hwupgrade.org/public/style_emoticons/default/lol.png

Nientedimeno dalla versione 4(e siamo alla 7) http://www.hwupgrade.org/public/style_emoticons/default/lol.png
Bisognerebbe avvertirli, magari non lo sanno :D

Certo che si puo' scrivere una funzioncina jni o javacpp. Si puo' sempre fare. C'e' chi pero' preferisce non farlo, per una pletora di motivi...

[Vincenzo1968]

Ah dunque, per via dell'antipatia che si ha verso il C, ci si tiene la versione buggata! LOL, SUPERLOL, SUPERMEGALOOOOOOOLLLLLLL!

http://www.hwupgrade.org/public/style_emoticons/default/lol.png

super http://www.hwupgrade.org/public/style_emoticons/default/lol.png

super mega http://www.hwupgrade.org/public/style_emoticons/default/lol.png

[sottovento]

Ah dunque, per via dell'antipatia che si ha verso il C, ci si tiene la versione buggata! LOL, SUPERLOL, SUPERMEGALOOOOOOOLLLLLLL!

http://www.hwupgrade.org/public/style_emoticons/default/lol.png

super http://www.hwupgrade.org/public/style_emoticons/default/lol.png

super mega http://www.hwupgrade.org/public/style_emoticons/default/lol.png
Guarda, io sono un poveretto, per di piu' che viene dalla bassa. Non so per quale motivo non l'abbiano [ancora] sistemato e per quale motivo questo bug ha vita cosi' lunga.
Se mi servisse la suddetta funzione, valuterei costi/benefici e potrei decidere di implementarla. Siamo tutti d'accordo che l'implementazione e' triviale.

Ma si dice che la testa di quei signori sia visibile dallo spazio (non come la muraglia cinese), quindi avranno i loro buoni motivi

[Vincenzo1968]

EDIT: -

[Prince_81]

penso sarà per un fatto di sicurezza, resta il fatto però che comporta grossi limiti.

[sottovento]

penso sarà per un fatto di sicurezza, resta il fatto però che comporta grossi limiti.
Ci stavo pensando anch'io, soprattutto in riferimento al fatto che java deve girare su una risma di dispositivi molto diversi tra di loro.
Comunque puoi sempre risolvere con una piccola jni.

[VICIUS]

Ci stavo pensando anch'io, soprattutto in riferimento al fatto che java deve girare su una risma di dispositivi molto diversi tra di loro.
Comunque puoi sempre risolvere con una piccola jni.

isHidden fa già uso di jni.


public boolean isHidden() {
SecurityManager security = System.getSecurityManager();
if (security != null) {
security.checkRead(path);
}
return ((fs.getBooleanAttributes(this) & FileSystem.BA_HIDDEN) != 0);
}
…
public abstract int getBooleanAttributes(File f);
…
static private FileSystem fs = FileSystem.getFileSystem();
…
public static native FileSystem getFileSystem();

Il bug sarà da qualche parte nel codice della jvm che implementa FileSystem per i sistemi di mamma ms.

Leggendo il bug report che hai postato poco sopra mi pare poi di leggere che anche il programma attrib di windows ha gli stesi problemi. Probabilmente quella parte di api ha una documentazione più oscena del solito. Se anche la stessa microsoft non è in grado di dirti se un file è nascosto c'è un grosso problema di fondo.

[The_ouroboros]

Microsoft... Sempre una certezza!

Inviato dal mio Sony Xperia P

[sottovento]

<cut>
Leggendo il bug report che hai postato poco sopra mi pare poi di leggere che anche il programma attrib di windows ha gli stesi problemi. Probabilmente quella parte di api ha una documentazione più oscena del solito. Se anche la stessa microsoft non è in grado di dirti se un file è nascosto c'è un grosso problema di fondo.

Si. Fra l'altro viene anche specificata la soluzione, disattesa da Microsoft stessa:

When GetFileAttributes is called on a directory containing a volume mount point, the file attributes returned are those of the directory where the volume mount point is set, not those of the root directory in the target mounted volume. To obtain the file attributes of the mounted volume, call GetVolumeNameForVolumeMountPoint to obtain the name of the target volume. Then use the resulting name in a call to GetFileAttributes. The results will be the attributes of the root directory on the target volume.


Alla fine:

This is still an issue in jdk7. The simplest solution is to ignore the DOS hidden attributes for directories (as the hidden attribute has different semantics on directories). The new file system API (java.nio.file) does not suffer from this issue.

Forse e' per via dell'ultima frase che hanno rinunciato a sistemare il bug.

@Prince_81 - utilizzando infatti il package java.nio.file, dovresti riuscire ad ottenere il flag corretto

[banryu79]

Non è meglio scriversi una bella dll in C? Una funzioncina da richiamare tramite JNI?

http://www.hwupgrade.org/public/style_emoticons/default/challenge.png

Bug irrisolto http://www.hwupgrade.org/public/style_emoticons/default/lol.png

Nientedimeno dalla versione 4(e siamo alla 7) http://www.hwupgrade.org/public/style_emoticons/default/lol.png
Criticare a random cose che non si conoscono a fondo... :asd:

[Vincenzo1968]

Criticare a random cose che non si conoscono a fondo... :asd:

http://www.hwupgrade.org/public/style_emoticons/default/lol.png

Ti posto un codice win api(cervellotica) che mostra i file normali e quelli nascosti di una directory?

Cervellotica, si, ma funzionante. Quello che non funziona è l'implementazione jni della jvm.

http://www.hwupgrade.org/public/style_emoticons/default/lol.png

[Vincenzo1968]

// http://msdn.microsoft.com/it-it/library/windows/desktop/aa365200(v=vs.85).aspx


#include <windows.h>
#include <tchar.h>
#include <stdio.h>
#include <strsafe.h>
#pragma comment(lib, "User32.lib")

void DisplayErrorBox(LPTSTR lpszFunction);

int _tmain(int argc, TCHAR *argv[])
{
WIN32_FIND_DATA ffd;
LARGE_INTEGER filesize;
TCHAR szDir[MAX_PATH];
size_t length_of_arg;
HANDLE hFind = INVALID_HANDLE_VALUE;
DWORD dwError=0;

// If the directory is not specified as a command-line argument,
// print usage.

if(argc != 2)
{
_tprintf(TEXT("\nUsage: %s <directory name>\n"), argv[0]);
return (-1);
}

// Check that the input path plus 3 is not longer than MAX_PATH.
// Three characters are for the "\*" plus NULL appended below.

StringCchLength(argv[1], MAX_PATH, &length_of_arg);

if (length_of_arg > (MAX_PATH - 3))
{
_tprintf(TEXT("\nDirectory path is too long.\n"));
return (-1);
}

_tprintf(TEXT("\nTarget directory is %s\n\n"), argv[1]);

// Prepare string for use with FindFile functions. First, copy the
// string to a buffer, then append '\*' to the directory name.

StringCchCopy(szDir, MAX_PATH, argv[1]);
StringCchCat(szDir, MAX_PATH, TEXT("\\*"));

// Find the first file in the directory.

hFind = FindFirstFile(szDir, &ffd);

if (INVALID_HANDLE_VALUE == hFind)
{
DisplayErrorBox(TEXT("FindFirstFile"));
return dwError;
}

// List all the files in the directory with some info about them.

do
{
if (ffd.dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY)
{
_tprintf(TEXT(" %s <DIR>\n"), ffd.cFileName);
}
else
{
if ( !(ffd.dwFileAttributes & FILE_ATTRIBUTE_HIDDEN) )
{
filesize.LowPart = ffd.nFileSizeLow;
filesize.HighPart = ffd.nFileSizeHigh;
_tprintf(TEXT(" %s %ld bytes\n"), ffd.cFileName, filesize.QuadPart);
}
}
}
while (FindNextFile(hFind, &ffd) != 0);

dwError = GetLastError();
if (dwError != ERROR_NO_MORE_FILES)
{
DisplayErrorBox(TEXT("FindFirstFile"));
}

FindClose(hFind);
return dwError;
}


void DisplayErrorBox(LPTSTR lpszFunction)
{
// Retrieve the system error message for the last-error code

LPVOID lpMsgBuf;
LPVOID lpDisplayBuf;
DWORD dw = GetLastError();

FormatMessage(
FORMAT_MESSAGE_ALLOCATE_BUFFER |
FORMAT_MESSAGE_FROM_SYSTEM |
FORMAT_MESSAGE_IGNORE_INSERTS,
NULL,
dw,
MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT),
(LPTSTR) &lpMsgBuf,
0, NULL );

// Display the error message and clean up

lpDisplayBuf = (LPVOID)LocalAlloc(LMEM_ZEROINIT,
(lstrlen((LPCTSTR)lpMsgBuf)+lstrlen((LPCTSTR)lpszFunction)+40)*sizeof(TCHAR));
StringCchPrintf((LPTSTR)lpDisplayBuf,
LocalSize(lpDisplayBuf) / sizeof(TCHAR),
TEXT("%s failed with error %d: %s"),
lpszFunction, dw, lpMsgBuf);
MessageBox(NULL, (LPCTSTR)lpDisplayBuf, TEXT("Error"), MB_OK);

LocalFree(lpMsgBuf);
LocalFree(lpDisplayBuf);
}


Nella cartella C:\Prova ho due file nascosti: hello.exe e prova.bc.

http://img16.imageshack.us/img16/4660/hidden01u.jpg

Se commento la parte che dice di non mostrare i file nascosti:

http://img600.imageshack.us/img600/8598/hidden02.jpg

http://www.hwupgrade.org/public/style_emoticons/default/lol.png

super http://www.hwupgrade.org/public/style_emoticons/default/lol.png

super mega http://www.hwupgrade.org/public/style_emoticons/default/lol.png

[Vincenzo1968]

Il bug sarà da qualche parte nel codice della jvm che implementa FileSystem per i sistemi di mamma ms.

Leggendo il bug report che hai postato poco sopra mi pare poi di leggere che anche il programma attrib di windows ha gli stesi problemi. Probabilmente quella parte di api ha una documentazione più oscena del solito. Se anche la stessa microsoft non è in grado di dirti se un file è nascosto c'è un grosso problema di fondo.


if ( !(ffd.dwFileAttributes & FILE_ATTRIBUTE_HIDDEN) )
{
filesize.LowPart = ffd.nFileSizeLow;
filesize.HighPart = ffd.nFileSizeHigh;
_tprintf(TEXT(" %s %ld bytes\n"), ffd.cFileName, filesize.QuadPart);
}


http://www.hwupgrade.org/public/style_emoticons/default/lol.png

super http://www.hwupgrade.org/public/style_emoticons/default/lol.png

super mega http://www.hwupgrade.org/public/style_emoticons/default/lol.png

[Vincenzo1968]

http://www.ibm.com/developerworks/java/tutorials/j-jni/

[sottovento]

super mega

Scriviamolo ancora, per sicurezza:

When GetFileAttributes is called on a directory containing a volume mount point, the file attributes returned are those of the directory where the volume mount point is set, not those of the root directory in the target mounted volume. To obtain the file attributes of the mounted volume, call GetVolumeNameForVolumeMountPoint to obtain the name of the target volume. Then use the resulting name in a call to GetFileAttributes. The results will be the attributes of the root directory on the target volume.


Il problema e' di Microsoft Windows, e ne e' affetto anche il tuo codice, visto che effettui le identiche chiamate

[Vincenzo1968]

Scriviamolo ancora, per sicurezza:

Il problema e' di Microsoft Windows, e ne e' affetto anche il tuo codice, visto che effettui le identiche chiamate

Dove la vedi la chiamata a GetFileAttributes nel "mio" codice?

http://img685.imageshack.us/img685/4531/hidden03.jpg

Kiss.jpg e SitiFileUpload.txt sono file nascosti nel "mount volume" F:
Nella seconda chiamata il programma è stato ricompilato commentando il codice che non mostra i file nascosti:

// http://msdn.microsoft.com/it-it/library/windows/desktop/aa365200(v=vs.85).aspx


#include <windows.h>
#include <tchar.h>
#include <stdio.h>
#include <strsafe.h>
#pragma comment(lib, "User32.lib")

void DisplayErrorBox(LPTSTR lpszFunction);

int _tmain(int argc, TCHAR *argv[])
{
WIN32_FIND_DATA ffd;
LARGE_INTEGER filesize;
TCHAR szDir[MAX_PATH];
size_t length_of_arg;
HANDLE hFind = INVALID_HANDLE_VALUE;
DWORD dwError=0;

// If the directory is not specified as a command-line argument,
// print usage.

if(argc != 2)
{
_tprintf(TEXT("\nUsage: %s <directory name>\n"), argv[0]);
return (-1);
}

// Check that the input path plus 3 is not longer than MAX_PATH.
// Three characters are for the "\*" plus NULL appended below.

StringCchLength(argv[1], MAX_PATH, &length_of_arg);

if (length_of_arg > (MAX_PATH - 3))
{
_tprintf(TEXT("\nDirectory path is too long.\n"));
return (-1);
}

_tprintf(TEXT("\nTarget directory is %s\n\n"), argv[1]);

// Prepare string for use with FindFile functions. First, copy the
// string to a buffer, then append '\*' to the directory name.

StringCchCopy(szDir, MAX_PATH, argv[1]);
StringCchCat(szDir, MAX_PATH, TEXT("\\*"));

// Find the first file in the directory.

hFind = FindFirstFile(szDir, &ffd);

if (INVALID_HANDLE_VALUE == hFind)
{
DisplayErrorBox(TEXT("FindFirstFile"));
return dwError;
}

// List all the files in the directory with some info about them.

do
{
if (ffd.dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY)
{
_tprintf(TEXT(" %s <DIR>\n"), ffd.cFileName);
}
else
{
//if ( !(ffd.dwFileAttributes & FILE_ATTRIBUTE_HIDDEN) )
//{
filesize.LowPart = ffd.nFileSizeLow;
filesize.HighPart = ffd.nFileSizeHigh;
_tprintf(TEXT(" %s %ld bytes\n"), ffd.cFileName, filesize.QuadPart);
//}
}
}
while (FindNextFile(hFind, &ffd) != 0);

dwError = GetLastError();
if (dwError != ERROR_NO_MORE_FILES)
{
DisplayErrorBox(TEXT("FindFirstFile"));
}

FindClose(hFind);
return dwError;
}


void DisplayErrorBox(LPTSTR lpszFunction)
{
// Retrieve the system error message for the last-error code

LPVOID lpMsgBuf;
LPVOID lpDisplayBuf;
DWORD dw = GetLastError();

FormatMessage(
FORMAT_MESSAGE_ALLOCATE_BUFFER |
FORMAT_MESSAGE_FROM_SYSTEM |
FORMAT_MESSAGE_IGNORE_INSERTS,
NULL,
dw,
MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT),
(LPTSTR) &lpMsgBuf,
0, NULL );

// Display the error message and clean up

lpDisplayBuf = (LPVOID)LocalAlloc(LMEM_ZEROINIT,
(lstrlen((LPCTSTR)lpMsgBuf)+lstrlen((LPCTSTR)lpszFunction)+40)*sizeof(TCHAR));
StringCchPrintf((LPTSTR)lpDisplayBuf,
LocalSize(lpDisplayBuf) / sizeof(TCHAR),
TEXT("%s failed with error %d: %s"),
lpszFunction, dw, lpMsgBuf);
MessageBox(NULL, (LPCTSTR)lpDisplayBuf, TEXT("Error"), MB_OK);

LocalFree(lpMsgBuf);
LocalFree(lpDisplayBuf);
}


http://www.hwupgrade.org/public/style_emoticons/default/lol.png

super http://www.hwupgrade.org/public/style_emoticons/default/lol.png

super mega http://www.hwupgrade.org/public/style_emoticons/default/lol.png

[sottovento]

super mega

Ok, te lo scrivo ancora. Ma poi il thread diventa noioso, pertanto non te lo scrivo piu':


When GetFileAttributes is called on a directory containing a volume mount point, the file attributes returned are those of the directory where the volume mount point is set, not those of the root directory in the target mounted volume. To obtain the file attributes of the mounted volume, call GetVolumeNameForVolumeMountPoint to obtain the name of the target volume. Then use the resulting name in a call to GetFileAttributes. The results will be the attributes of the root directory on the target volume.

[Vincenzo1968]

Ma non uso GetFileAttributes!

LOOOOLLLL!!!

Ho postato pure l'esempio col mount volume F! Ma, sant'iddio, negate pure l'evidenza? LOOOOOOOOLLLLLLL!!!

[Vincenzo1968]

Per quanto riguarda l'ostinarsi a non voler utilizzare C/JNI è il caso di citare Knuth:

In other words, it, seems that fanatical advocates of the New Programming are going overboard in their strict enforcement of morality and purity in programs.

[sottovento]

super mega


Devo quotare ancora, mi spiace:

utilizzando infatti il package java.nio.file, dovresti riuscire ad ottenere il flag corretto

[Vincenzo1968]

https://github.com/twall/jna#readme

http://www.hwupgrade.org/public/style_emoticons/default/lol.png


Java Native Access (JNA)

The definitive JNA reference (including an overview and usage details) is in the JavaDoc. Please read the overview.

JNA provides Java programs easy access to native shared libraries (DLLs on Windows) without writing anything but Java code—no JNI or native code is required. This functionality is comparable to Windows' Platform/Invoke and Python's ctypes. Access is dynamic at runtime without code generation.

JNA allows you to call directly into native functions using natural Java method invocation. The Java call looks just like it does in native code. Most calls require no special handling or configuration; no boilerplate or generated code is required.

The JNA library uses a small native library stub to dynamically invoke native code. The developer uses a Java interface to describe functions and structures in the target native library. This makes it quite easy to take advantage of native platform features without incurring the high overhead of configuring and building JNI code for multiple platforms.

While some attention is paid to performance, correctness and ease of use take priority.

JNA includes a platform library with many native functions already mapped as well as a set of utility interfaces that simplify native access.

[Vincenzo1968]

Devo quotare ancora, mi spiace:

E pure io, mi dispiace, devo quotare ancora:

Il problema e' di Microsoft Windows, e ne e' affetto anche il tuo codice, visto che effettui le identiche chiamate

Mi dici dove ne è affetto anche il mio codice? E com'è che funziona l'esempio che ho postato sopra? Per virtù dello spirito santo?

Mi mostri le identiche chiamate?

[sottovento]

E pure io, mi dispiace, devo quotare ancora:

Mi dici dove ne è affetto anche il mio codice? E com'è che funziona l'esempio che ho postato sopra? Per virtù dello spirito santo?

Mi mostri le identiche chiamate?

Sai, hai l'abitudine di postare chilometri di codice e uno si deve affidare a quanto dice la documentazione, visto che la notizia viene direttamente da Microsoft :D Non avevo dato un'occhiata al tuo codice, tutto qui. (si tratta di MSDN, giusto?)
Parere personale: e' meglio sempre cercare di dare l'idea, prima di tutto, e non dare per scontato che tutti abbiano tempo e voglia di guardare il codice. Anche perche' poi finisce che magari qualcuno lo guarda :D
E soprattutto (sempre parere personale) non e' nemmeno bello scrivere tutti quei LOL, perche' si fa un po' la figura di quello che sa tutto e che gli altri siano dei poveretti che non sanno (o non sanno fare) nulla.
Nel mio caso e' sicuramente vero, ma stiamo parlando di personale tecnico di altissimo livello che lavorano in Sun/Oracle e Microsoft per sviluppare software che verra' distribuito in milioni di copie. Immagino che l'idea di scrivere lo stesso codice che hai scritto tu l'avranno avuta anche loro.

Ad ogni modo, visto che l'hai chiesto, sono tornato sui miei passi e controllato il codice.

Diciamo quindi che, nel caso uno si trovi a dover scrivere del software in Java, per esempio per listare una directory e si trovasse davanti ad un bug di Java, come in questo caso, ha davanti a se' qualche opzione.

Cito le prime che mi vengono in mente:
1 - mi tengo il bug cosi' com'e' (non e' male, dipende dai casi);
2 - controllo se c'e' un work-around o una soluzione migliore. In effetti, la soluzione migliore in questo caso esiste (non e' un workaround, e' un miglioramento, e per questo hanno deciso di non cambiare piu' il vecchio codice). Perche' hanno deciso di non cambiare piu' il vecchio codice? Occorrerebbe chiederlo a loro, ma posso azzardare: ormai il codice buggato e' cosi' consolidato ed in uso da cosi' tanto tempo che c'e' la paura di chiudere un bug ma creare malfunzionamenti a tante altre applicazioni.
3 - mi riscrivo il metodo mancante in un altro linguaggio, per esempio C/C++ e lo chiamo da Java attraverso jni;

Certo, prima di passare al punto #3, uno valuta se i punti #1 e #2 sono applicabili. Perche'? I motivi sono tantissimi. Il primo di tutti e' ovviamente la portabilita'. Poi la correttezza e la robustezza.

Prendiamo per esempio il codice pubblicato da Vincenzo: e' scritto da una mano esperta (Microsoft) e con estrema cura.
Nonostante cio' il codice andra' in crash in almeno 4 punti diversi. Certo, e' solo un esempio, ma si vede che e' stata messa molto cura senza tuttavia riuscire ad evitare che il software possa andare in crash.

Inoltre il codice risultante non e' portabile.
ATTENZIONE - non dico portabile fra sistemi molto eterogenei, ma addirittura girera' solo su alcune particolari versioni di Windows, e solo fornite di alcuni Service Pack!!!
Su altre versioni di Window non partira' neppure, su altre andra' in crash alla partenza.
Aggiungendo quindi questo software, pur scritto ottimamente, si introdurranno delle serie instabilita' nell'applicazione, e tutto per avere un flag di HIDE. Vale la pena di chiedersi se e' meglio tenersi il bug, giusto?

Chi ha scritto il codice e' anche stato costretto a risolvere il problema del nome del file (e delle stringhe) in formato ASCII/UNICODE, cioe' a gestire i due diversi formati di stringhe, altrimenti il codice sarebbe stato ulteriormente limitato. Si e' quindi creato un NUOVO, FITTIZIO problema (prima non l'avevamo :D ), necessitante di una nuova soluzione, pena altri crash.
Un nuovo problema che prima non c'era, quindi.

Cosi', abbiamo un nuovo progetto da gestire, oltre a quelli Java. La DLL risultante dovra' poi essere correttamente installata, il progetto gestito e tutto il resto. E' molto probabile che serva anche un nuovo ambiente di sviluppo.
Il codice proposto e' oltretutto un esempio di lettura di directory; in realta' dobbiamo creare il codice jni. Occorre quindi generare altro codice, controllare ancora la documentazione per il passaggio dei dati da/verso i due ambienti, controllare come si fa, per esempio, a creare un ArrayList<String> da C++ e ritornarlo a Java, ecc.

Naturalmente ogni modifica richiede la modifica di piu' progetti.
Accedere a strutture dati Java da C++ e' possibilissimo. Chi pero' l'ha fatto, sa che occorre perderci tempo, fare le cose precise precise, ....
Insomma, alla fine funzione ma serve perderci tempo.

E' fattibile? Sicuramente!!! Lo fanno tutti i giorni. Pero' ogni giorno si valutano i costi e benefici. In questo caso, per esempio.....

[Vincenzo1968]

Certo però che nemmeno guardare il codice e sentenziare:

Il problema e' di Microsoft Windows, e ne e' affetto anche il tuo codice, visto che effettui le identiche chiamate

Mah! Mi verrebbe da mettere la faccina lol ma, visto che ti da tanto fastidio non la metto. Metto solo: mah!

[sottovento]

Certo però che nemmeno guardare il codice e sentenziare:

Il problema e' di Microsoft Windows, e ne e' affetto anche il tuo codice, visto che effettui le identiche chiamate

Mah! Mi verrebbe da mettere la faccina lol ma, visto che ti da tanto fastidio non la metto. Metto solo: mah!

Hai ragione, non ho scusanti. :ave:
(e per i LOL: a me puoi metterli, mi scocciava solo che li mettessi ad altri, senza tentare almeno di capire le motivazioni che hanno garantito vita lunga a quel bug).

Ok, straparlo. Vado a dormire. Scusa ancora

[Vincenzo1968]

Comunque vediamo di addivenire a una conclusione(addivenire! LOL!!!). La mia è questa:

Se le prestazioni non sono un problema(es. bisogna leggere i file in una sola cartella con pochi file) allora usiamo nio e buonanotte:


package filelist;
import java.io.IOException;
import java.nio.file.*;
import java.nio.file.attribute.*;

public class FileList {
public static void main(String[] args) {
Path file = FileSystems.getDefault().getPath("F:\\Prova", "myfile.txt");
try {
DosFileAttributes attr =
Files.readAttributes(file, DosFileAttributes.class);
System.out.println("isReadOnly is " + attr.isReadOnly());
System.out.println("isHidden is " + attr.isHidden());
System.out.println("isArchive is " + attr.isArchive());
System.out.println("isSystem is " + attr.isSystem());
} catch (UnsupportedOperationException x) {
System.err.println("DOS file" +
" attributes not supported:" + x);
}
catch(IOException io)
{
System.out.println("IOException" + io.getMessage());
}
}
}


In caso contrario usiamo jni o, meglio ancora, jna. Inutile intestardirsi a volere usare solo Java. Io ho già dei bei benchmark pronti. Ci sarebbe da ridere a postarli. Altro che faccine lollose.

In other words, it, seems that fanatical advocates of the New Programming are going overboard in their strict enforcement of morality and purity in programs. Donald E. Knuth

[sottovento]

Comunque vediamo di addivenire a una conclusione(addivenire! LOL!!!). La mia è questa:

Se le prestazioni non sono un problema(es. bisogna leggere i file in una sola cartella con pochi file) allora usiamo nio e buonanotte:

<cut>

In caso contrario usiamo jni o, meglio ancora, jna. Inutile intestardirsi a volere usare solo Java. Io ho già dei bei benchmark pronti. Ci sarebbe da ridere a postarli. Altro che faccine lollose.

Diciamo: in caso contrario ed in caso che la piattaforma sia ben nota.

Ho una domanda: secondo te, a cosa dipende la differenza di prestazioni che hai rilevato (su MS-Win, giusto?).
Cmq puoi pubblicare i tuoi benchmark, insieme ad una versione del tuo software.
Come abbiamo visto precedentemente, introdurremo degli elementi di criticita' nel progetto visto che ci sono crash, ed il software non girera' nemmeno su tutte le versioni di Windows. Ma magari questo non e' un problema.



In other words, it, seems that fanatical advocates of the New Programming are going overboard in their strict enforcement of morality and purity in programs. Donald E. Knuth

Se non ricordo male, si riferiva all'uso del goto: i puristi additati in questa frase, secondo Knuth, sono quelli che pretendono l'eliminazione totale del goto, e per questo Knuth li chiama "fanatical advocates" e prevede che il loro software, che persegue appunto questo "strict enforcement of morality and purity in programs" li porta ad avere cattive prestazioni, addirittura tempi doppi rispetto ai programmi scritti con l'uso del goto. Sbaglio?

Supponiamo di no. Beh, non mi sembra che c'entri molto col discorso che stiamo affrontando

[VICIUS]

Se le prestazioni non sono un problema(es. bisogna leggere i file in una sola cartella con pochi file) allora usiamo nio e buonanotte:
…
In caso contrario usiamo jni o, meglio ancora, jna.

È esattamente il contrario. Se la cartella contiene milioni di file quando chiami una ipotetica listaFileConJni("c:\cartella") che ritorna la lista con le istanze di File cosa succede? Prima di tutto il thread si blocca in quel punto per decine di minuti finché la funzione non ha finito di leggere la cartella e i file. Dovendo costruire una lista con milioni di istanze di File l'heap finisce molto in fretta e c'è il rischio che il programma venga ucciso a metà da un OutOfMemoryException. Una volta ritornata la lista devi comunque scorrerla completamente alla ricerca di quello che ti serve.

Con java puoi leggere il contenuto della cartella con un iteratore. In memoria c'è sempre e solo un singolo file quindi quindi ram occupata zero e puoi decidere se un file ti interessa mentre lo stai leggendo senza scorrere liste. Per non parlare del fatto che codice scritto in java sarebbe portabile senza modifiche. Potrei lanciare il .class sulla lavatrice, il portatile nuovo o il mega cluster di 4000 macchine su aws e andrebbe senza ri-compilare fregandomene bellamente del sistema operativo, dell'architettura delle cpu e tutto il resto.

[sottovento]

È esattamente il contrario. Se la cartella contiene milioni di file quando chiami una ipotetica listaFileConJni("c:\cartella") che ritorna la lista con le istanze di File cosa succede? Prima di tutto il thread si blocca in quel punto per decine di minuti finché la funzione non ha finito di leggere la cartella e i file. Dovendo costruire una lista con milioni di istanze di File l'heap finisce molto in fretta e c'è il rischio che il programma venga ucciso a metà da un OutOfMemoryException. Una volta ritornata la lista devi comunque scorrerla completamente alla ricerca di quello che ti serve.

Con java puoi leggere il contenuto della cartella con un iteratore. In memoria c'è sempre e solo un singolo file quindi quindi ram occupata zero e puoi decidere se un file ti interessa mentre lo stai leggendo senza scorrere liste. Per non parlare del fatto che codice scritto in java sarebbe portabile senza modifiche. Potrei lanciare il .class sulla lavatrice, il portatile nuovo o il mega cluster di 4000 macchine su aws e andrebbe senza ri-compilare fregandomene bellamente del sistema operativo, dell'architettura delle cpu e tutto il resto.
Ma a che ora ti alzi? :D

Si, cmq volevo arrivare agli iteratori ;)
Pero' analizzare la differenza di prestazioni puo' essere interessante, a meno di credere che chi ha scritto Java abbia inserito delle NOP semplicemente per rallentare. Insomma, se la differenza di prestazioni e' notevole, ci deve essere un motivo valido

[VICIUS]

Ma a che ora ti alzi? :D

Si, cmq volevo arrivare agli iteratori ;)

Il mattino a l'oro in bocca. Io è già più di un oretta che sono in piedi :O

[franksisca]

ho letto tutto, e tralasciando l'ot, non vedo l'ora di vedere il confronto, sono sempre stato curioso sugli impatti della jvm nelle applicazioni

[Vincenzo1968]

È esattamente il contrario. Se la cartella contiene milioni di file quando chiami una ipotetica listaFileConJni("c:\cartella") che ritorna la lista con le istanze di File cosa succede? Prima di tutto il thread si blocca in quel punto per decine di minuti finché la funzione non ha finito di leggere la cartella e i file. Dovendo costruire una lista con milioni di istanze di File l'heap finisce molto in fretta e c'è il rischio che il programma venga ucciso a metà da un OutOfMemoryException. Una volta ritornata la lista devi comunque scorrerla completamente alla ricerca di quello che ti serve.

Con java puoi leggere il contenuto della cartella con un iteratore. In memoria c'è sempre e solo un singolo file quindi quindi ram occupata zero e puoi decidere se un file ti interessa mentre lo stai leggendo senza scorrere liste. Per non parlare del fatto che codice scritto in java sarebbe portabile senza modifiche. Potrei lanciare il .class sulla lavatrice, il portatile nuovo o il mega cluster di 4000 macchine su aws e andrebbe senza ri-compilare fregandomene bellamente del sistema operativo, dell'architettura delle cpu e tutto il resto.

Ma la mia dll usa un algoritmo iterativo(leggasi: non ricorsivo) per attraversare l'albero delle directory. E i benckmark li ho fatti non sulla cartella "C:\cartella" ma "C:", cioè l'intero disco.

Libro consigliato:

http://www.amazon.it/Thinking-Recursively-Java-Eric-Roberts/dp/0471701467
http://ecx.images-amazon.com/images/I/413ccVAdH3L._SL500_AA300_.jpg

Io ho la prima edizione, in Pascal. L'ultima edizione è in Java(si capisce dal sottotitolo?).

L'ultimo capitolo spiega come trasformare un algoritmo ricorsivo in iterativo.

;)

[Vincenzo1968]

ho letto tutto, e tralasciando l'ot, non vedo l'ora di vedere il confronto, sono sempre stato curioso sugli impatti della jvm nelle applicazioni

Potremmo aprirci un contest.

http://www.hwupgrade.org/public/style_emoticons/default/challenge.png

[Vincenzo1968]

Stavo pensando che, visto che la faccina-lol vi da tanto fastidio, d'ora innanzi, per muovere una qualche critica a Java potrei utilizzare, al suo posto, una citaziozione. Potrei citare, cioè, un utente che stimate moltissimo e per il quale non avete mai sollevato obiezioni tipo "ah ma dietro Java ci stanno fior di programmatori...".

La frase è questa:

Java: se lo conosci, lo eviti. Se lo conosci non ti uccide. Se non lo conosci, però, campi anche meglio.(cit.).

Che ne dite? (dico a Banryu, Vicius e Sottovento).

[sottovento]

Potremmo aprirci un contest.

http://www.hwupgrade.org/public/style_emoticons/default/challenge.png

Non so come funzionano i contest qui; tuttavia il software che hai pubblicato, come ti ho detto, sarebbe fuori concorso visto che va in crash

[sottovento]

Stavo pensando che, visto che la faccina-lol vi da tanto fastidio, d'ora innanzi, per muovere una qualche critica a Java potrei utilizzare, al suo posto, una citaziozione. Potrei citare, cioè, un utente che stimate moltissimo e per il quale non avete mai sollevato obiezioni tipo "ah ma dietro Java ci stanno fior di programmatori...".

La frase è questa:

Java: se lo conosci, lo eviti. Se lo conosci non ti uccide. Se non lo conosci, però, campi anche meglio.(cit.).

Che ne dite? (dico a Banryu, Vicius e Sottovento).

cdmauro muove le critiche al linguaggio, tu alle persone. E' diverso

[Vincenzo1968]

cdmauro muove le critiche al linguaggio, tu alle persone. E' diverso

Ah quindi per te è più offensivo criticare ogni tanto con la faccina lollosa piuttosto che avere quella frase in firma!

Scusa ma qui ci vuole:
http://www.hwupgrade.org/public/style_emoticons/default/lol.png
(senza offesa eh!)

Non è offensivo, per i programmatori che si sono fatti un mazzo tanto, dire che Java, se lo eviti, campi anche meglio. Noooooooooo!

:mc:

Evitalo allora, che campi anche meglio. Programma in C#. ;)

[Vincenzo1968]

Altro libro consigliato:

http://www.amazon.com/Think-About-Algorithms-Jeff-Edmonds/dp/0521614104
http://ecx.images-amazon.com/images/I/310malb7J1L._BO2,204,203,200_PIsitb-sticker-arrow-click-small,TopRight,12,-30_AA300_SH20_OU01_.jpg

[cdimauro]

Se non riesci a capire la differenza fra linguaggio e utilizzatore, hai serii problemi.

Non ho mai mosso critiche insensate a un linguaggio: ho sempre fornito AMPIE argomentazioni in merito, ed è da quello che è scaturita quella frase. Visto che ti piace tanto ricercare e hai tanto tempo per farlo, vai pure a controllare il thread in cui è nato tutto.

Non ho mai mosso critiche a chi utilizza un linguaggio: sui gusti non si discute, perché ognuno ha i suoi. Lo ripeto qui DA ANNI, ma forse ti sarà sfuggito. Ricontrolla anche questo, visto che hai tempo.

Infine, rileggi i tuoi messaggi in questo thread, e chiediti se hanno senso le tue uscite. Mi sembri un fanatico integralista che ogni critica al C la vede come un attacco personale, addirittura un'offesa. Ma la cosa più divertente è che vedi critiche anche quando non ce n'è nemmeno l'ombra, com'è capitato proprio in questo thread, all'inizio.

Ciò detto, impara almeno la cosa più importante: "First make it work"...

[Vincenzo1968]

hai serii problemi.


Serii http://www.hwupgrade.org/public/style_emoticons/default/lol.png

Ah già, dimenticavo: uno con te deve sempre contestualizzare. Se uno degli sviluppatori Java leggesse quella frase non si offenderebbe, no!
Il tizio direbbe: "no, aspetta un attimo, bisogna contestualizzare! Vediamo un po' come nasce quella frase. Aspetta che mi cerco il thread...".

http://www.hwupgrade.org/public/style_emoticons/default/patpat.gif

[Vincenzo1968]

Comunque ho deciso: d'ora in poi, quando devo muovere qualche critica su un aspetto che non mi piace di Java, invece di usare la faccina-LOL scrivo:

"Java: se lo conosci, lo eviti. Se lo conosci non ti uccide. Se non lo conosci, però, campi anche meglio".

Tanto si tratta di una normale critica al linguaggio...
http://www.hwupgrade.org/public/style_emoticons/default/dumb.png.

Se qualcuno dovesse offendersi potrei sempre rispondergli: "no, un minuto, devi contestualizzare! Cercati il thread dove ho deciso di usare la frase".

;)

[cdimauro]

Sapevo che ti saresti attaccato a quello. Ecco qui: La verità, vi prego, sul plurale dei termini in -io (http://www.accademiadellacrusca.it/it/lingua-italiana/consulenza-linguistica/domande-risposte/verit-prego-plurale-termini)

Sul resto nemmeno rispondo, perché continui a trollare, per cui ti lascio l'ultima parola, così sei contento.

Comunque la prossima volta evita di citarmi, perché non leggo tutti i thread. Questo mi è stato indicato da un altro utente, altrimenti mi sarebbe sfuggito. Grazie.

[Vincenzo1968]

Stavo cercando il thread sull'origine della frase(dato che non ho mai niente da fare ;) ) e mi sono imbattuto in questa perla:

http://www.hwupgrade.it/forum/showpost.php?p=29602117&postcount=1451

I storici... :rotfl:

Tu hai serii problemi con l'italiano.

Uh! serii! abbiamo il novello Calvino che scrive i plurali delle parole terminanti in io nella forma anticheggiante...

http://www.hwupgrade.org/public/style_emoticons/default/dumb.png

Me lo indichi il thread in questione? Sennò c'è il rischio che m'imbatta in altre perle come "i storici"...

http://www.hwupgrade.org/public/style_emoticons/default/lol.png

[The_ouroboros]

Torniamo it, pretty please?

Inviato dal mio Sony Xperia P

[Vincenzo1968]

Lui non offende mai nessuno:

http://www.hwupgrade.org/topic/5837-ecco-a-voi-il-pi%C3%B9-grande-esperto-di-sistemi-operativi-lol/
http://img442.imageshack.us/img442/9677/spalaremerda.jpg

Chissa come saranno contenti i programmatori di openoffice dopo questa critica costruttiva e per nulla offensiva...

http://www.hwupgrade.org/public/style_emoticons/default/lol.png

[VICIUS]

Ma la mia dll usa un algoritmo iterativo(leggasi: non ricorsivo) per attraversare l'albero delle directory. E i benckmark li ho fatti non sulla cartella "C:\cartella" ma "C:", cioè l'intero disco.
Vedo che non hai ben chiara la differenza tra un iteratore ed un ciclo for. Ti consiglio di googlare un attimo e chiarirti le idee se vuoi continuare la discussione.

[Vincenzo1968]

Grandi, grandissimi gli autori di questi post:

http://www.hwupgrade.it/forum/showpost.php?p=18906850&postcount=9
http://www.hwupgrade.it/forum/showpost.php?p=18938877&postcount=75
http://www.hwupgrade.it/forum/showpost.php?p=18944975&postcount=93
http://www.hwupgrade.it/forum/showpost.php?p=18946618&postcount=98
http://www.hwupgrade.it/forum/showpost.php?p=18947752&postcount=108
http://www.hwupgrade.it/forum/showpost.php?p=18949630&postcount=138
http://www.hwupgrade.it/forum/showpost.php?p=18949672&postcount=139
http://www.hwupgrade.it/forum/showpost.php?p=18954023&postcount=165
http://www.hwupgrade.it/forum/showpost.php?p=18956211&postcount=170
http://www.hwupgrade.it/forum/showpost.php?p=18957020&postcount=175
http://www.hwupgrade.it/forum/showpost.php?p=18976477&postcount=209
http://www.hwupgrade.it/forum/showpost.php?p=18977946&postcount=214
http://www.hwupgrade.it/forum/showpost.php?p=18978106&postcount=215

http://www.hwupgrade.it/forum/showpost.php?p=18984007&postcount=2
http://www.hwupgrade.it/forum/showpost.php?p=18984620&postcount=5
http://www.hwupgrade.it/forum/showpost.php?p=18985736&postcount=13
http://www.hwupgrade.it/forum/showpost.php?p=18986381&postcount=21
http://www.hwupgrade.it/forum/showpost.php?p=18987364&postcount=26
http://www.hwupgrade.it/forum/showpost.php?p=18991333&postcount=33
http://www.hwupgrade.it/forum/showpost.php?p=18994586&postcount=45
http://www.hwupgrade.it/forum/showpost.php?p=18994595&postcount=46
http://www.hwupgrade.it/forum/showpost.php?p=18994728&postcount=47
http://www.hwupgrade.it/forum/showpost.php?p=19031041&postcount=63
http://www.hwupgrade.it/forum/showpost.php?p=19034237&postcount=71
http://www.hwupgrade.it/forum/showpost.php?p=19034396&postcount=76
http://www.hwupgrade.it/forum/showpost.php?p=19034513&postcount=84
http://www.hwupgrade.it/forum/showpost.php?p=19034526&postcount=85
http://www.hwupgrade.it/forum/showpost.php?p=19034594&postcount=88
http://www.hwupgrade.it/forum/showpost.php?p=19034623&postcount=89
http://www.hwupgrade.it/forum/showpost.php?p=19034660&postcount=92
http://www.hwupgrade.it/forum/showpost.php?p=19034684&postcount=95
http://www.hwupgrade.it/forum/showpost.php?p=19050094&postcount=124
http://www.hwupgrade.it/forum/showpost.php?p=19074620&postcount=150
http://www.hwupgrade.it/forum/showpost.php?p=19074924&postcount=151
http://www.hwupgrade.it/forum/showpost.php?p=19091557&postcount=168
http://www.hwupgrade.it/forum/showpost.php?p=19124973&postcount=188
http://www.hwupgrade.it/forum/showpost.php?p=19130152&postcount=195
http://www.hwupgrade.it/forum/showpost.php?p=19131689&postcount=197
http://www.hwupgrade.it/forum/showpost.php?p=19132883&postcount=200
http://www.hwupgrade.it/forum/showpost.php?p=19137065&postcount=205
http://www.hwupgrade.it/forum/showpost.php?p=19138150&postcount=209
http://www.hwupgrade.it/forum/showpost.php?p=19139455&postcount=211
http://www.hwupgrade.it/forum/showpost.php?p=19141116&postcount=214
http://www.hwupgrade.it/forum/showpost.php?p=19141458&postcount=215

Banryu sarà senz'altro d'accordo, almeno per PGI-Bis. ;)



Affermazione: ho sempre consigliato pascal infatti, ma anche imparare il C non è la fine del mondo.

Risposta: Lo è: è fra i più brutti, contorti e inutili linguaggi della storia dei linguaggi di programmazione.

Provate a indovinare di chi è la risposta.
http://www.hwupgrade.it/forum/showpost.php?p=19078501&postcount=155

[Vincenzo1968]

È esattamente il contrario. Se la cartella contiene milioni di file quando chiami una ipotetica listaFileConJni("c:\cartella") che ritorna la lista con le istanze di File cosa succede? Prima di tutto il thread si blocca in quel punto per decine di minuti finché la funzione non ha finito di leggere la cartella e i file. Dovendo costruire una lista con milioni di istanze di File l'heap finisce molto in fretta e c'è il rischio che il programma venga ucciso a metà da un OutOfMemoryException. Una volta ritornata la lista devi comunque scorrerla completamente alla ricerca di quello che ti serve.

Con java puoi leggere il contenuto della cartella con un iteratore. In memoria c'è sempre e solo un singolo file quindi quindi ram occupata zero e puoi decidere se un file ti interessa mentre lo stai leggendo senza scorrere liste. Per non parlare del fatto che codice scritto in java sarebbe portabile senza modifiche. Potrei lanciare il .class sulla lavatrice, il portatile nuovo o il mega cluster di 4000 macchine su aws e andrebbe senza ri-compilare fregandomene bellamente del sistema operativo, dell'architettura delle cpu e tutto il resto.

Che lista con milioni di istanze? Dobbiamo fare un programmino che percorra l'albero delle directory a partire dal nodo radice(/C: su Windows) e stampi una serie di statistiche: quanti sono i file, quante sono le directory, quanti sono i file nascosti, quanti quelli normali, etc. Se proprio vogliamo stampare la lista dei file la facciamo stampare su file.

Facciamoci un contestino e poi vediamo. Magari Sottovento aggiungerà le criticità che, a suo dire, dovrebbero mandare in crash la mia dll(ma non penserà mica che il codice dell'esempio MSDN che ho postato è quello della mia dll?).

;)

[VICIUS]

Che lista con milioni di istanze? Dobbiamo fare un programmino che percorra l'albero delle directory a partire dal nodo radice(/C: su Windows) e stampi una serie di statistiche: quanti sono i file, quante sono le directory, quanti sono i file nascosti, quanti quelli normali, etc. Se proprio vogliamo stampare la lista dei file la facciamo stampare su file.

Facciamoci un contestino e poi vediamo. Magari Sottovento aggiungerà le criticità che, a suo dire, dovrebbero mandare in crash la mia dll(ma non penserà mica che il codice dell'esempio MSDN che ho postato è quello della mia dll?).

;)
A proporre di leggere l'intero contenuto di una intera directory con jni sei stato tu.

Del contest non c'è bisogno. Nello stesso messaggio parli anche di benchmarks che mi pare di capire parlano chiaro. Posta quelli che dovrebbero bastare. ;)

[Vincenzo1968]

A proporre di leggere l'intero contenuto di una intera directory con jni sei stato tu.

Del contest non c'è bisogno. Nello stesso messaggio parli anche di benchmarks che mi pare di capire parlano chiaro. Posta quelli che dovrebbero bastare. ;)

No è che non capisco questo: "l'heap finisce molto in fretta e c'è il rischio che il programma venga ucciso a metà da un OutOfMemoryException. Una volta ritornata la lista devi comunque scorrerla completamente alla ricerca di quello che ti serve."

Perché dovrebbe accadere con jni? Si tratta di richiamare una funzioncina all'interno della dll. Non c'e nessuna lista da scorrere. Perché il programma dovrebbe venire ucciso a metà?

E, no, i benchmarck miei non bastano. Se dici che c'è un modo più efficiente con gli iteratori è meglio confrontare Java-iteratore con Java-jni. Quindi ci vuole il contestino altrimenti ti fischieranno le orecchie per le imprecazioni di Franksisca. ;)

[VICIUS]

Ho capito. I bench erano fuffa. :asd:

[Vincenzo1968]

Ho capito. I bench erano fuffa. :asd:

Apri il contest e te ne accorgerai. :)

Almeno vuoi postare un esempio con gli iteratori? Un programmino che attraversi una cartella e dica quanti file nascosti e quanti normali ci sono all'interno?

[VICIUS]

Sono sicuro che c'è un esempio già pronto nel javadoc. Usa quello ;)

[banryu79]

Banryu sarà senz'altro d'accordo, almeno per PGI-Bis. ;)

Eh... per me leggere i post di PGI è sempre fonte di ispirazione.

[Vincenzo1968]

Eqque qua:

http://www.filedropper.com/findnew

Uso l'esempio javadoc adattato però per contare i file nascosti e normali:

http://img849.imageshack.us/img849/2292/viciusbench01.jpg

778 secondi contro 20 secondi.

778 secondi: leggasi: 13 minuti

20 secondi: leggasi: un terzo di minuto

Mi verrebbe da mettere la faccina LOL ma non vi piace :mad: :boh:

EDIT: dimenticavo: i file(la dll e l'eseguibile windows) sono stati creati con Visual Studio 2012. Quindi potrebbe essere necessario, per poter eseguire il pogramma, installare i runtime del compilatore che potete scaricare gratuitamente da qui:

http://www.microsoft.com/it-it/download/details.aspx?id=30679

;)

[Vincenzo1968]

Ah dimenticavo: nella mia dll ho usato l'algoritmo ricorsivo. Se usassi l'algoritmo iterativo ci impiegherebbe molto meno tempo.

Vediamo chi ha il coraggio di negare che, in situazioni come queste, non sarebbe il caso di usare Java-C(via JNI o, meglio, via JNA).

http://www.hwupgrade.org/public/style_emoticons/default/challenge.png

[Vincenzo1968]

Eh... per me leggere i post di PGI è sempre fonte di ispirazione.

Grande PGI-Bis! Com'è che non posta più? L'avete fatto incazzare come con repne? :mad:

[Vincenzo1968]

https://github.com/twall/jna#readme

Java Native Access (JNA)

The definitive JNA reference (including an overview and usage details) is in the JavaDoc. Please read the overview.

JNA provides Java programs easy access to native shared libraries (DLLs on Windows) without writing anything but Java code—no JNI or native code is required. This functionality is comparable to Windows' Platform/Invoke and Python's ctypes. Access is dynamic at runtime without code generation.

JNA allows you to call directly into native functions using natural Java method invocation. The Java call looks just like it does in native code. Most calls require no special handling or configuration; no boilerplate or generated code is required.

The JNA library uses a small native library stub to dynamically invoke native code. The developer uses a Java interface to describe functions and structures in the target native library. This makes it quite easy to take advantage of native platform features without incurring the high overhead of configuring and building JNI code for multiple platforms.

While some attention is paid to performance, correctness and ease of use take priority.

JNA includes a platform library with many native functions already mapped as well as a set of utility interfaces that simplify native access.

;)

[Vincenzo1968]

Comunque vale davvero la pena di rileggerseli con attenzione questi due magnifici thread:

http://www.hwupgrade.it/forum/showthread.php?p=18906850#post18906850

http://www.hwupgrade.it/forum/showthread.php?p=18984007#post18984007

Ancora non ho trovato il thread che dovrebbe giustificare quella squallida frase in firma :confused:

[Vincenzo1968]

ho letto tutto, e tralasciando l'ot, non vedo l'ora di vedere il confronto, sono sempre stato curioso sugli impatti della jvm nelle applicazioni

;)

[shinya]

778 secondi: leggasi: 13 minuti

20 secondi: leggasi: un terzo di minuto

Mi verrebbe da mettere la faccina LOL ma non vi piace :mad: :boh:
Prima dei tempi guarderei i risultati, che sono diversi...

[Vincenzo1968]

Prima dei tempi guarderei i risultati, che sono diversi...

Perché Java, a un certo punto, lancia, non si sa perché, l'eccezione AccessDeniedException sulla cartella C:\Qoobox\BackEnv; si vede nell'immagine postata.

Ma quello è codice preso da JavaDoc come m'avete consigliato. Postate il vostro codice che rifaccio i benchmark. ;)

Inoltre, Shinya, puoi accertarti della bontà dell'applicazione C provandola su una cartella con pochi file. Marcane qualcuno col flag hidden e vedi. ;)

[Vincenzo1968]

dio maledica Sun, Gosling e tutti quelli che hanno collaborato a questo strumento del diavolo.(cit.)

Indovinate, di chi è la frase citata?

http://www.hwupgrade.it/forum/showpost.php?p=37001802&postcount=2

Sottovento, che è? che dici?

Il linguaggio critica, non le persone che ci lavorano: "Sun è assolutamente indifendibile su queste porcate da dilettanti allo sbaraglio.".

Sottove', 'mbé?

EDIT:

Josling & soci dovevano andare a zappare invece di fare tutto questo danno.

http://www.hwupgrade.it/forum/showpost.php?p=35510139&postcount=17

[sottovento]

dio maledica Sun, Gosling e tutti quelli che hanno collaborato a questo strumento del diavolo.(cit.)

Indovinate, di chi è la frase citata?

http://www.hwupgrade.it/forum/showpost.php?p=37001802&postcount=2

Sottovento, che è? che dici?

Il linguaggio critica, non le persone che ci lavorano: "Sun è assolutamente indifendibile su queste porcate da dilettanti allo sbaraglio.".

Sottove', 'mbé?

Questo e' l'ultimo messaggio che scrivo, e' meglio che mi prenda una pausa da questo forum.

Evidentemente sono io che ho frainteso: sai, quando scrivi LOL, metti ometti a braccia conserte e tutto l'armamentario, significa che stai ridendo in faccia al tuo interlocutore, vuoi sottolineare il fatto che la tua controparte ha detto una c...ta.
Molti di questi interlocutori possono pensarla in maniera diversa da te, ma non e' un buon motivo per questo comportamento.
Ho cercato di fartelo notare, ma hai risposto andando a prendere qua e la' dei messaggi, tentando di giustificare il tuo comportamento.
Giustificatissimo!! Continua pure cosi', alla grande. Piace a tutti. Non badare a me, io ho una cosa da fare, non rispondero' piu'.
Sui forum puo' capitare di avere diverbi ed anche arrabbiarsi con chi la pensa in maniera diversa e vede come fenomenale una tecnologia o un linguaggio che ti fa schifo. Ma onestamente, non ho mai trovato nessuno offensivo, nonostante i toni accesi. Stiamo parlando di cose soggettive, quindi il problema puo' essere benissimo mio, ma non sono l'unico a sentirsi offeso dal tuo modo di fare.
Se vuoi un suggerimento da amico, prova a pensare a queste parole, potresti guadagnarci. Anzi, ci guadagneremmo tutti. So che non puoi lasciare l'ultima parola a nessuno e quindi il mio post scatenera' un'altra ridda di risposte.
Non preoccuparti, non ne leggero' nemmeno una.

Ad ogni modo: come sempre, il tuo programma C++ e' SBAGLIATO. Succede, quando si scrive software per umiliare gli altri, dev'esserci una specie di legge del contrappasso informatico.
Meglio scriverlo ancora: SBAGLIATO. Nella mia directory di test avevo 9 files, nessuno hidden ed ovviamente ne ha trovato un altro numero.

Veniamo ora al programma java. Con una piccola modifica (che non pubblichero' per evitare continui scorni), ho ottenuto i risultati seguenti (riporto anche quelli del tuo programma, anche se fuori concorso perche' errato - serve solo per riferimento con i tempi):



C:\LastMessageInForum>ptime ViciudFindFile64 c:\

ptime 1.0 for Win32, Freeware - http://www.pc-tools.net/
Copyright(C) 2002, Jem Berkes <jberkes@pc-tools.net>

=== ViciudFindFile64 c:\ ===


Hidden : 3539
Other : 390305
Total : 393844


Execution time: 13.804 s

C:\LastMessageInForum>ptime java -jar ScanDir.jar c:\

ptime 1.0 for Win32, Freeware - http://www.pc-tools.net/
Copyright(C) 2002, Jem Berkes <jberkes@pc-tools.net>

=== java -jar ScanDir.jar c:\ ===
Hidden: 1371
Regular:341736

Execution time: 42.025 s
C:\LastMessageInForum>




Naturalmente, questo taglia la testa al toro, visto che monto un disco da mezzo tera: PASSARE AL C++ NON CONVIENE NEMMENO IN QUESTO CASO!!
Si tratta di pochi secondi in piu' per scandire l'intero hard disk, e produrre il risultato CORRETTO (verificato).

Questo e' importante, ho deciso di scrivere ancora questo messaggio per evitare che qualcuno, impressionato dalle prestazioni che hai pubblicato, fosse tentato di fare un grave errore, buttare via portabilita', robustezza e tutto il resto, solo per ottenere una prestazione migliore.
Non c'e' alcuna prestazione migliore.

D'altronde era ragionevole: si tratta di una chiamata di sistema, ed effettuarla da C++ invece che da Java non dovrebbe cambiare troppo, no?

L'unica cosa che cambia, e' che Java qualcosa di piu', ovvero un sistema piu' robusto di controllo degli accessi (i.e. le eccezioni di cui parlavi), che giustifica l'overhead.

Per inciso: questa e' solo la prima prova, e' scontato che possa migliorare ancora i tempi, ma non era questo lo scopo. E poi, come dicevo, ho una cosa importante da fare

[Vincenzo1968]

Ad ogni modo: come sempre, il tuo programma C++ e' SBAGLIATO. Succede, quando si scrive software per umiliare gli altri, dev'esserci una specie di legge del contrappasso informatico.
Meglio scriverlo ancora: SBAGLIATO. Nella mia directory di test avevo 9 files, nessuno hidden ed ovviamente ne ha trovato un altro numero.

L'unica cosa che mi sono dimenticato è che il mio programma conta anche le cartelle nascoste, non soltanto i file. Che sia sbagliato lo dici tu. Io ho effettuato parecchie prove e funziona perfettamente.

E che io voglia umiliare qualcuno lo dici tu. Non mi sono mai sognato di umiliare nessuno e tantomeno Vicius che, nonostante le discussioni accese e i litigi, mi sta simpatico.
Avevo chiesto, a Vicius, di postare un suo esempio e m'ha risposto di cercarmelo su JavaDoc. Io quello ho trovato. Tu hai risolto migliorando notevolmente i tempi; posta il codice, nell'interesse generale. ;)

Dai che posto la versione iterativa e confrontiamo i tempi. ;)

[Vincenzo1968]

Eqque qua:

http://img138.imageshack.us/img138/1658/viciusbench02.jpg

Ho modificato il mio programma in modo da fargli contare solo i file e non anche le cartelle.
Come mai la versione Java trova soltanto 86 file quando sono invece 88 come correttamente riportato dalla mia versione C? Ripeto, il programmino Java l'ho copiato dai JavaDoc come consigliatomi da Vicius.

Questo? Taglia la testa al toro? :)

[Vincenzo1968]

E questo? La taglia la testa al toro?

http://img191.imageshack.us/img191/3094/viciusbench03.jpg

:)

[VICIUS]

E questo? La taglia la testa al toro?

http://img191.imageshack.us/img191/3094/viciusbench03.jpg

:)

Prima di tutto voglio farti notare una piccola incongruenza nei dati che hai riportato oggi. Nella prima prova la versione Java risulta quasi 39 volte più lenta della versione C. In quest'ultima è invece solo 4 volte più lenta. Immagino che entrambi i programmi non abbiano subito modifiche tra le due prove. Ma allora come mai? Prova a pensarci che no è difficile da capire. :)

Per quanto riguarda il tuo programmino java io avrei usato DirectoryStream. Anche SimpleFileVisitor può andare bene ma è più lento perché legge da solo gli attributi standard di tutti i file che a te non interessano. L'errore grave è stato usare DosFileAttributes. Usando quella classe rendi non portabile il tuo programma su altri sistemi. In java c'è Files.isHidden() che fa già quello in maniera portabile. L'uso di PathMatcher se poi gli passi "*.*" e non dai la possibilità di modificare il pattern è completamente inutile. Se provi a riscriverlo potresti migliorarlo un po' rendendo i tempi simili alla versione C.

[Vincenzo1968]

Prima di tutto voglio farti notare una piccola incongruenza nei dati che hai riportato oggi. Nella prima prova la versione Java risulta quasi 39 volte più lenta della versione C. In quest'ultima è invece solo 4 volte più lenta. Immagino che entrambi i programmi non abbiano subito modifiche tra le due prove. Ma allora come mai? Prova a pensarci che no è difficile da capire. :)

Per quanto riguarda il tuo programmino java io avrei usato DirectoryStream. Anche SimpleFileVisitor può andare bene ma è più lento perché legge da solo gli attributi standard di tutti i file che a te non interessano. L'errore grave è stato usare DosFileAttributes. Usando quella classe rendi non portabile il tuo programma su altri sistemi. In java c'è Files.isHidden() che fa già quello in maniera portabile. L'uso di PathMatcher se poi gli passi "*.*" e non dai la possibilità di modificare il pattern è completamente inutile. Se provi a riscriverlo potresti migliorarlo un po' rendendo i tempi simili alla versione C.

Ho aggiorato il link con la nuova versione che conta solo i file e non le cartelle.

C'è anche la versione Java che, dietro tuo consiglio, mi sono andato a cercare su JavaDoc. Fai le prove e facci sapere. Quindi "il tuo" non è "il tuo" ma "il loro", di JavaDoc. ;)

Non sarebbe il caso di postare un po' di codice a questo punto? :) Io, essendo niubbo di Java più di questo non so fare. Postatele le vostre versioni invece di criticare e basta. ;)

[Vincenzo1968]

E comunque, Vicius, già una volta, nel contest 19, mi avevi accusato di barare sui tempi. Poi s'è scoperto, grazie a AnonimoVeneziano, che era un discorso di disco lento sul tuo portatile.

Vabbé che mi stai simpatico, però, vedi di non approfittarne eh! ;)

[VICIUS]

E comunque, Vicius, già una volta, nel contest 19, mi avevi accusato di barare sui tempi. Poi s'è scoperto, grazie a AnonimoVeneziano, che era un discorso di disco lento sul tuo portatile.

Vabbé che mi stai simpatico, però, vedi di non approfittarne eh! ;)

Non ti sto accusando di barare. Ti ho solo fatto notare che i tuoi numeri non tornano. Io so perché la prima misurazione che hai fatto è completamente sballata. Ti ho suggerito di indagare perché magari impari qualcosa.

[VICIUS]

Ho aggiorato il link con la nuova versione che conta solo i file e non le cartelle:

http://www.filedropper.com/viciusfindfilenew

C'è anche la versione Java che, dietro tuo consiglio, mi sono andato a cercare su JavaDoc. Fai le prove e facci sapere. Quindi "il tuo" non è "il tuo" ma "il loro", di JavaDoc. ;)

Non sarebbe il caso di postare un po' di codice a questo punto? :) Io, essendo niubbo di Java più di questo non so fare. Postatele le vostre versioni invece di criticare e basta. ;)

Se avessi voluto criticare e basta mi sarebbe bastato darti del incompetente chiudendo con un "super mega lol + faccina".

Invece ti ho detto dove secondo me hai sbagliato e cosa potresti fare per migliorare il tuo programma. Sono stato piuttosto costruttivo.

[Vincenzo1968]

Sul portatilino i tempi migliorano:

http://img266.imageshack.us/img266/874/viciusbench04.jpg

http://img694.imageshack.us/img694/9581/viciusbench05.jpg

Fino a quando non posterete il codice riterrò validi quest benchmark. E non perché non vi creda. Credo che Sottovento sia riuscito veramente a ridurre notevolmente i tempi dell'applicazione Java(a patto però che faccia restituire il conteggio corretto ;) ). Ma faccio come avete fatto voi con me: se non postate il codice(o perlomeno l'eseguibile,(.class, .jar)) io cito Vicius: la vostra è fuffa.

;)

[Vincenzo1968]

Domani posto la versione iterativa che è molto più veloce della versione ricorsiva. E allora sarete definitivamente spacciati.

Se qualcuno fosse interessato ai sorgenti, può averli contattandomi in pvt. ;)

Ciao.

[Vincenzo1968]

Per quanto riguarda il tuo programmino java io avrei usato DirectoryStream. Anche SimpleFileVisitor può andare bene ma è più lento perché legge da solo gli attributi standard di tutti i file che a te non interessano. L'errore grave è stato usare DosFileAttributes. Usando quella classe rendi non portabile il tuo programma su altri sistemi. In java c'è Files.isHidden() che fa già quello in maniera portabile. L'uso di PathMatcher se poi gli passi "*.*" e non dai la possibilità di modificare il pattern è completamente inutile. Se provi a riscriverlo potresti migliorarlo un po' rendendo i tempi simili alla versione C.

Porca mignotta, questa m'era sfuggita! Ma non abbiamo detto che non funziona, che è buggato? Non s'era detto di usare NIO?

Ciao a tutti,
volevo chiedervi come mai mentre cerco di visualizzare file e cartelle con il seguente codice:


File file=new File("C:\\");
File f[]=file.listFiles();

for(int i=0;i<f.length;i++){
if(!f[i].isHidden()){
System.out.println(f[i].getPath());
}
}



nonostanche abbia usato l'istruzione if(!f[i].isHidden()) alcune cartelle e alcuni file di sistema o semplicemente invisibili vengono visualizzati nell'output?

[Vincenzo1968]

Sono riuscito a ridurre i tempi della versione Java:

http://img853.imageshack.us/img853/9915/viciusbench06.jpg


/*
* http://docs.oracle.com/javase/tutorial/displayCode.html?code=http://docs.oracle.com/javase/tutorial/essential/io/examples/Find.java.
*/

import java.io.*;
import java.nio.file.*;
import java.nio.file.attribute.*;
import static java.nio.file.FileVisitResult.*;
import static java.nio.file.FileVisitOption.*;
import java.util.*;

public class Find {

public static class Finder
extends SimpleFileVisitor<Path> {

//private final PathMatcher matcher;
//private int numMatches = 0;
private int numHidden = 0;
private int numOther = 0;

//Finder(String pattern) {
// matcher = FileSystems.getDefault()
// .getPathMatcher("glob:" + pattern);
//}

// Compares the glob pattern against
// the file or directory name.
void find(Path file) {
Path name = file.getFileName();
try {
if (name != null /*&& matcher.matches(name)*/ ) {
DosFileAttributes attr = Files.readAttributes(file, DosFileAttributes.class);
if ( attr.isHidden() )
numHidden++;
else
numOther++;
//numMatches++;
//System.out.println(file);
}
} catch (UnsupportedOperationException x) {
System.err.println("DOS file" + " attributes not supported:" + x);
}
catch(IOException io)
{
System.out.println("IOException" + io.getMessage());
}
}

// Prints the total number of
// matches to standard out.
void done() {
System.out.println("Hidden : " + numHidden);
System.out.println("Other : " + numOther);
System.out.println("Matched: " + (numHidden + numOther));
}

// Invoke the pattern matching
// method on each file.
@Override
public FileVisitResult visitFile(Path file,
BasicFileAttributes attrs) {
find(file);
return CONTINUE;
}

// Invoke the pattern matching
// method on each directory.
@Override
public FileVisitResult preVisitDirectory(Path dir,
BasicFileAttributes attrs) {
find(dir);
return CONTINUE;
}

@Override
public FileVisitResult visitFileFailed(Path file,
IOException exc) {
System.err.println(exc);
return CONTINUE;
}
}

static void usage() {
System.err.println("java Find <path>");
System.exit(-1);
}

public static void main(String[] args)
throws IOException {

if (args.length < 1)
usage();

Path startingDir = Paths.get(args[0]);
//String pattern = "*.*";

//Finder finder = new Finder(pattern);
Finder finder = new Finder();
Files.walkFileTree(startingDir, finder);
finder.done();
}
}

[Vincenzo1968]

http://img571.imageshack.us/img571/5025/viciusbench07.jpg
.

[VICIUS]

Porca mignotta, questa m'era sfuggita! Ma non abbiamo detto che non funziona, che è buggato? Non s'era detto di usare NIO?

No attento. Files con la "s" finale.

[banryu79]

Porca mignotta, questa m'era sfuggita! Ma non abbiamo detto che non funziona, che è buggato? Non s'era detto di usare NIO?
Quello di prima era java.io.File, questo invece è java.nio.Files

[Vincenzo1968]

Ah ok.

Com'è che su Windows XP continua a metterci una vita? :confused:

http://img690.imageshack.us/img690/6965/viciusbenchnew01.jpg

[Vincenzo1968]

Ah ok.

http://img850.imageshack.us/img850/5152/viciusbenchnew02.jpg


import java.io.*;
import java.nio.file.*;

public class Find {

static void usage() {
System.err.println("java Find <path>");
System.exit(-1);
}

public static void main(String[] args) throws IOException {

int numHidden = 0;
int numOther = 0;

if (args.length < 1)
usage();

try (DirectoryStream<Path> ds =
Files.newDirectoryStream(FileSystems.getDefault().getPath(args[0]))) {for (Path p : ds) {

if ( Files.isHidden(p) )
numHidden++;
else
numOther++;
}

} catch (IOException e) {
e.printStackTrace();
}

System.out.println("Hidden : " + numHidden);
System.out.println("Other : " + numOther);
System.out.println("Matched: " + (numHidden + numOther));
}

}

[Vincenzo1968]

Ah no:


import java.io.*;
import java.nio.file.*;

public class Find {

static void usage() {
System.err.println("java Find <path>");
System.exit(-1);
}

public static void main(String[] args) throws IOException {

int numHidden = 0;
int numOther = 0;

if (args.length < 1)
usage();

try (DirectoryStream<Path> ds =
Files.newDirectoryStream(FileSystems.getDefault().getPath(args[0]))) {for (Path p : ds) {

if ( !Files.isDirectory(p) ){
if ( Files.isHidden(p) )
numHidden++;
else
numOther++;
}
}

} catch (IOException e) {
e.printStackTrace();
}

System.out.println("Hidden : " + numHidden);
System.out.println("Other : " + numOther);
System.out.println("Matched: " + (numHidden + numOther));
}

}


Ma continua a dare un numero sbagliato di file. Nella cartella "C:\Contest19" ci sono 8 file e me ne da, invece, 7.
e, inoltre, come faccio a leggere tutti i file nelle sottocartelle?

[Vincenzo1968]

import java.nio.file.*;
import java.nio.file.attribute.*;
import static java.nio.file.FileVisitResult.*;
import java.io.IOException;
import java.util.*;

public class Find {

static class TreeVisitor implements FileVisitor<Path> {

private int numHidden = 0;
private int numOther = 0;

public void done() {
System.out.println("Hidden : " + numHidden);
System.out.println("Other : " + numOther);
System.out.println("Matched: " + (numHidden + numOther));
}

@Override
public FileVisitResult preVisitDirectory(Path dir, BasicFileAttributes attrs) {
return CONTINUE;
}

@Override
public FileVisitResult visitFile(Path file, BasicFileAttributes attrs) {
//if ( !Files.isDirectory(p) ){
try {
if ( Files.isHidden(file) )
numHidden++;
else
numOther++;
} catch (IOException e) {
e.printStackTrace();
}
//}
return CONTINUE;
}

@Override
public FileVisitResult postVisitDirectory(Path dir, IOException exc) {
if (exc != null)
System.err.println("WARNING: " + exc);
return CONTINUE;
}

@Override
public FileVisitResult visitFileFailed(Path file, IOException exc) {
System.err.println("WARNING: " + exc);
return CONTINUE;
}
}

static void usage() {
System.err.println("java Find <path>");
System.exit(-1);
}

public static void main(String[] args) throws IOException {
if (args.length < 1)
usage();
int argi = 1;
int maxDepth = Integer.MAX_VALUE;

TreeVisitor visitor = new TreeVisitor();

Set<FileVisitOption> opts = Collections.emptySet();
while (argi < args.length) {
Path file = Paths.get(args[argi]);
Files.walkFileTree(file, opts, maxDepth, visitor);
argi++;
}

visitor.done();
}
}


Mi restituisce 0 file nella cartella "C:\Contest19".

[Vincenzo1968]

Possiamo concludere che non c'è modo, in Java, di ottenere il numero di file nascosti in una cartella? O volete postare il vostro codice?

http://img221.imageshack.us/img221/343/viciusbenchnew03.jpg

[Vincenzo1968]

Ah no:

http://img4.imageshack.us/img4/435/viciusbenchnew04.jpg


import java.nio.file.*;
import java.nio.file.attribute.*;
import static java.nio.file.FileVisitResult.*;
import java.io.IOException;
import java.util.*;

public class Find {

static class TreeVisitor implements FileVisitor<Path> {

private int numHidden = 0;
private int numOther = 0;

public void done() {
System.out.println("Hidden : " + numHidden);
System.out.println("Other : " + numOther);
System.out.println("Matched: " + (numHidden + numOther));
}

@Override
public FileVisitResult preVisitDirectory(Path dir, BasicFileAttributes attrs) {
return CONTINUE;
}

@Override
public FileVisitResult visitFile(Path file, BasicFileAttributes attrs) {
//if ( !Files.isDirectory(file) ){
try {
if ( Files.isHidden(file) )
numHidden++;
else
numOther++;
} catch (IOException e) {
e.printStackTrace();
}
//}
return CONTINUE;
}

@Override
public FileVisitResult postVisitDirectory(Path dir, IOException exc) {
if (exc != null)
System.err.println("WARNING: " + exc);
return CONTINUE;
}

@Override
public FileVisitResult visitFileFailed(Path file, IOException exc) {
System.err.println("WARNING: " + exc);
return CONTINUE;
}
}

static void usage() {
System.err.println("java Find <path>");
System.exit(-1);
}

public static void main(String[] args) throws IOException {
if (args.length < 1)
usage();
int maxDepth = Integer.MAX_VALUE;

TreeVisitor visitor = new TreeVisitor();

Set<FileVisitOption> opts = Collections.emptySet();
Path file = Paths.get(args[0]);
Files.walkFileTree(file, opts, maxDepth, visitor);

visitor.done();
}
}


Ma continua a dare un numero sbagliato di file.

[Vincenzo1968]

http://img607.imageshack.us/img607/142/viciusbenchnew05.jpg


using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.IO;

public class StackBasedIteration
{
private static int numHidden = 0;
private static int numOther = 0;

static void Main(string[] args)
{
TraverseTree(args[0]);

Console.WriteLine("Hidden: {0}", numHidden);
Console.WriteLine("Other : {0}", numOther);
Console.WriteLine("Total : {0}", numHidden + numOther);

}

public static void TraverseTree(string root)
{
Stack<string> dirs = new Stack<string>(20);

if (!System.IO.Directory.Exists(root))
{
throw new ArgumentException();
}
dirs.Push(root);

while (dirs.Count > 0)
{
string currentDir = dirs.Pop();
string[] subDirs;
try
{
subDirs = System.IO.Directory.GetDirectories(currentDir);
}
catch (UnauthorizedAccessException e)
{
Console.WriteLine(e.Message);
continue;
}
catch (System.IO.DirectoryNotFoundException e)
{
Console.WriteLine(e.Message);
continue;
}

string[] files = null;
try
{
files = System.IO.Directory.GetFiles(currentDir);
}
catch (UnauthorizedAccessException e)
{

Console.WriteLine(e.Message);
continue;
}
catch (System.IO.DirectoryNotFoundException e)
{
Console.WriteLine(e.Message);
continue;
}

foreach (string file in files)
{
try
{
System.IO.FileInfo fi = new System.IO.FileInfo(file);
//Console.WriteLine("{0}: {1}", fi.Name, fi.Attributes.ToString());
if ( (fi.Attributes & FileAttributes.Hidden) == FileAttributes.Hidden )
numHidden++;
else
numOther++;
}
catch (System.IO.FileNotFoundException e)
{
Console.WriteLine(e.Message);
continue;
}
}

foreach (string str in subDirs)
dirs.Push(str);
}
}
}

[Vincenzo1968]

http://www.filedropper.com/findnew

http://img145.imageshack.us/img145/2903/tempijavanew.jpg

http://img20.imageshack.us/img20/5336/tempicsharpnew.jpg

http://img138.imageshack.us/img138/7148/tempicnew.jpg

[Vincenzo1968]

CountFilesPython.py:

import os
import sys
if os.name== 'nt':
import win32api, win32con

numHidden = 0
numOther = 0

def isHidden(p):
if os.name== 'nt':
attribute = win32api.GetFileAttributes(p)
return attribute & win32con.FILE_ATTRIBUTE_HIDDEN
else:
return p.startswith('.') #linux

def walk(dir):
global numHidden
global numOther
try:
for name in os.listdir(dir):
path = os.path.join(dir, name)
if os.path.isfile(path):
#print path
if isHidden(path):
numHidden += 1
else:
numOther += 1
else:
walk(path)
except:
print "Errore: ", path

walk(sys.argv[1])

print "Hidden : ", numHidden
print "Other : ", numOther
print "Total : ", numHidden + numOther



http://img805.imageshack.us/img805/3789/countfilespython.jpg

http://img203.imageshack.us/img203/3209/countfilesjava.jpg

http://img163.imageshack.us/img163/6893/countfilescsharp.jpg

http://img801.imageshack.us/img801/4268/countfilesc.jpg


Si noti come la versione Java abbia tempi mostruosamente alti la prima volta che viene avviata.
E non si capisce perché mai l'utente debba avviare l'applicazione una seconda volta. Solo per poter dire: "Ah ma dalla seconda volta ci mette solo 30 secondi"?

Dunque la risposta alla domanda "vale la pena, in questo caso, utilizzare Java-C via JNI?" è: si! Si si. Siiiiiiiii!!!
Tenendo conto anche che la versione iterativa della dll ci mette poco più di 8 secondi per compiere il lavoro. ;)

La versione C#, invece, ha tempi accettabili fin dal primo avvio. Non buoni come la versione C, ma accettabili, ma, tutto sommato, buoni. ;)

La versione Python risulta la più veloce di tutte(ma solo dal secondo avvio, LOL!) ma restituisce un conteggio errato(erratissimo).

pypy da un messaggio di errore: "ImportError: No module named win32api" LOL!

[Vincenzo1968]

http://img18.imageshack.us/img18/9206/countfilesc19.jpg

;)

[Vincenzo1968]

Linux, finalmente! :D

http://img199.imageshack.us/img199/2523/countfileslinux.jpg

http://img202.imageshack.us/img202/1743/findexe.jpg

[Prince_81]

Alla fin fine riassumendo solo con java non si può risolvere il problema; che dire, speriamo che i programmatori java risolvano queto problema, magari dopo aver letto questo forum ;)

[Vincenzo1968]

Alla fin fine riassumendo solo con java non si può risolvere il problema; che dire, speriamo che i programmatori java risolvano queto problema, magari dopo aver letto questo forum ;)

Come sarebbe a dire? Si che si può in Java: basta utilizzare NIO. Scaricati il file .zip che ho postato e dai un'occhiata ai sorgenti:

http://www.filedropper.com/findnew

Il sorgente è: Find.java.

Il problema, casomai, è nella versione python(eh, ma non cominciamo! L'esempio l'ho preso dal sito ufficiale).

;)

[Vincenzo1968]

Anzi, è talmente breve che te lo posto per intero:


import java.nio.file.*;
import java.nio.file.attribute.*;
import static java.nio.file.FileVisitResult.*;
import java.io.IOException;
import java.util.*;

public class Find {

static class TreeVisitor implements FileVisitor<Path> {

private int numHidden = 0;
private int numOther = 0;

public void done() {
System.out.println("Hidden : " + numHidden);
System.out.println("Other : " + numOther);
System.out.println("Matched: " + (numHidden + numOther));
}

@Override
public FileVisitResult preVisitDirectory(Path dir, BasicFileAttributes attrs) {
return CONTINUE;
}

@Override
public FileVisitResult visitFile(Path file, BasicFileAttributes attrs) {
//if ( !Files.isDirectory(file) ){
try {
if ( Files.isHidden(file) )
numHidden++;
else
numOther++;
} catch (IOException e) {
e.printStackTrace();
}
//}
return CONTINUE;
}

@Override
public FileVisitResult postVisitDirectory(Path dir, IOException exc) {
if (exc != null)
System.err.println("WARNING: " + exc);
return CONTINUE;
}

@Override
public FileVisitResult visitFileFailed(Path file, IOException exc) {
System.err.println("WARNING: " + exc);
return CONTINUE;
}
}

static void usage() {
System.err.println("java Find <path>");
System.exit(-1);
}

public static void main(String[] args) throws IOException {
if (args.length < 1)
usage();
int maxDepth = Integer.MAX_VALUE;

TreeVisitor visitor = new TreeVisitor();

Set<FileVisitOption> opts = Collections.emptySet();
Path file = Paths.get(args[0]);
Files.walkFileTree(file, opts, maxDepth, visitor);

visitor.done();
}
}


;)

[Vincenzo1968]

Ruby :cool:


$numHidden = 0
$numOther = 0

def procdir(dirname)
begin
Dir.foreach(dirname) do |dir|
dirpath = dirname + '/' + dir
if File.directory?(dirpath) then
if dir != '.' && dir != '..' then
procdir(dirpath)
end
else
if File.basename(dirpath)[0] == '.' then
$numHidden += 1
else
$numOther += 1
end
end
end
rescue => e
puts e
end
end

procdir(ARGV[0])

puts "Hidden : #{$numHidden}"
puts "Hidden : #{$numOther}"
puts "Hidden : #{$numHidden + $numOther}"


http://img203.imageshack.us/img203/6627/tempiruby.jpg

[Vincenzo1968]

http://img580.imageshack.us/img580/7110/rubyversion.jpg

:cool:

[Vincenzo1968]

Nientedimeno C# con pinvoke è più veloce della mia dll. http://www.hwupgrade.org/public/style_emoticons/default/lol.png


http://img15.imageshack.us/img15/1889/tempiffnew.jpg



DirWalkCApi.cs:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.IO;
using System.Runtime.InteropServices;

namespace DirWalkCApi
{
class Program
{
private static int numHidden = 0;
private static int numOther = 0;

public const int MAX_PATH = 260;
public const int MAX_ALTERNATE = 14;

[StructLayout(LayoutKind.Sequential)]
public struct FILETIME
{
public uint dwLowDateTime;
public uint dwHighDateTime;
}

[StructLayout(LayoutKind.Sequential, CharSet = CharSet.Unicode)]
public struct WIN32_FIND_DATA
{
public FileAttributes dwFileAttributes;
public FILETIME ftCreationTime;
public FILETIME ftLastAccessTime;
public FILETIME ftLastWriteTime;
public uint nFileSizeHigh;
public uint nFileSizeLow;
public uint dwReserved0;
public uint dwReserved1;
[MarshalAs(UnmanagedType.ByValTStr, SizeConst = MAX_PATH)]
public string cFileName;
[MarshalAs(UnmanagedType.ByValTStr, SizeConst = MAX_ALTERNATE)]
public string cAlternate;
}

[DllImport("kernel32", CharSet = CharSet.Auto)]
public static extern IntPtr FindFirstFile(string lpFileName, out WIN32_FIND_DATA lpFindFileData);

[DllImport("kernel32", CharSet = CharSet.Auto)]
public static extern bool FindNextFile(IntPtr hFindFile, out WIN32_FIND_DATA lpFindFileData);

[DllImport("kernel32.dll")]
public static extern bool FindClose(IntPtr hFindFile);


public static void TraverseDirectory(string directoryPath)
{
IntPtr INVALID_HANDLE_VALUE = new IntPtr(-1);
WIN32_FIND_DATA findData;
char[] backslash = new char[] { '\\' };
IntPtr findHandle;
string path = string.Empty;

try
{
findHandle = FindFirstFile(directoryPath.TrimEnd(backslash) + @"\*", out findData);
if (findHandle != INVALID_HANDLE_VALUE)
{
do
{
path = string.Format("{0}\\{1}", directoryPath.TrimEnd(backslash), findData.cFileName);

if ((findData.dwFileAttributes & FileAttributes.Directory) != 0)
{
if (findData.cFileName != "." && findData.cFileName != "..")
{
TraverseDirectory(path);
}
}
else
{
if ((findData.dwFileAttributes & FileAttributes.Hidden) != 0)
numHidden++;
else
numOther++;
}
}
while (FindNextFile(findHandle, out findData));

FindClose(findHandle);
}
}
catch (System.ComponentModel.Win32Exception exc) // as suggested by John Saunders
{
int lastError = System.Runtime.InteropServices.Marshal.GetLastWin32Error();
Console.WriteLine("error:" + lastError.ToString());
//Console.WriteLine(exc.NativeErrorCode.ToString());
}
}


static void Main(string[] args)
{
TraverseDirectory(args[0].ToString());

Console.WriteLine("Hidden: {0}", numHidden);
Console.WriteLine("Other : {0}", numOther);
Console.WriteLine("Total : {0}", numHidden + numOther);
}
}
}


Vedete? Utilizzando le dll C native, C# risulta 3 volte più veloce. ;)

[Vincenzo1968]

Questi invece i tempi della mia versione iterativa:

http://img833.imageshack.us/img833/934/tempimyiterativeversion.jpg