[java] problemi con alcuni file e cartelle invisibili

[Vincenzo1968]

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

[sottovento]

Originariamente inviato da Vincenzo1968

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]

Originariamente inviato da sottovento

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?



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);
}

super

super mega

[sottovento]

Originariamente inviato da Vincenzo1968

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]

Originariamente inviato da Vincenzo1968

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




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]

Originariamente inviato da sottovento

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]

Originariamente inviato da Vincenzo1968

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 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
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 ), 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]

Originariamente inviato da 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!

Hai ragione, non ho scusanti.
(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]

Originariamente inviato da 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:

<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.

Originariamente inviato da Vincenzo1968

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]

Originariamente inviato da Vincenzo1968

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]

Originariamente inviato da VICIUS

È 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?

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]

Originariamente inviato da sottovento

Ma a che ora ti alzi?

Si, cmq volevo arrivare agli iteratori

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

[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]

Originariamente inviato da VICIUS

È 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-Recurs.../dp/0471701467


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]

Originariamente inviato da 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

Potremmo aprirci un contest.