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

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

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]

Originariamente inviato da Prince_81

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/1...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?



Bug irrisolto

Nientedimeno dalla versione 4(e siamo alla 7)

[sottovento]

Originariamente inviato da Vincenzo1968

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



Bug irrisolto

Nientedimeno dalla versione 4(e siamo alla 7)

Bisognerebbe avvertirli, magari non lo sanno

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!



super

super mega

[sottovento]

Originariamente inviato da Vincenzo1968

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



super

super mega

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]

Originariamente inviato da Prince_81

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]

Originariamente inviato da sottovento

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]

Originariamente inviato da VICIUS

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

Originariamente inviato da Vincenzo1968

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



Bug irrisolto

Nientedimeno dalla versione 4(e siamo alla 7)

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

[Vincenzo1968]

Originariamente inviato da banryu79

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

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.

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



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





super

super mega

[Vincenzo1968]

Originariamente inviato da VICIUS

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

super

super mega